This article describes how to transfer your current Arch Linux installation in or out of a virtual environment (i.e. QEMU, VirtualBox, VMware), and is heavily based on the Full System Backup with rsync article. A virtual machine ("VM", for short) uses different hardware, which needs to be addressed by re-generating the initramfs image. While any Linux filesystem should work, it's recommended that you go with ext4, at least at first, until you get the hang of it.

Chroot and reinstall the bootloader

Boot a "live" Linux distribution, mount the root partition and chroot into it:

# mount /dev/sdb2 /mnt
# arch-chroot /mnt

Reinstall either Syslinux or GRUB, using the instructions from the Beginners' Guide. Don't forget to update the configuration file (i.e. syslinux.cfg or grub.cfg).

Adjust the fstab

Since your entire root tree has been transferred to a single partition, edit the fstab file to reflect the right partition. Check with blkid (since lsblk is not very useful inside a chroot).

Re-generate the initramfs image

Because the hardware has changed, while you're still in the chroot, re-generate the initramfs image:

# mkinitcpio -p linux

And that's about it.

You'll most likely need to set up the network, since the virtual machine was probably piggybacking on the host OS's network settings. See Configure the network from the Beginners' Guide.

Moving into a VM

Moving into a virtual environment takes a little more effort.

Create the container

This will create a 10 GB raw image:

# dd if=/dev/zero of=/media/Backup/backup.img bs=1024 count=10482381

If you want to create one the exact size of your root partition, run fdisk -l and use the value from the Blocks column. Note that you will transfer you entire root tree, so that includes the /boot and /home folders. If you have any separate partitions for those, you need to take them into account when creating the container.

Now load the necessary module and mount it as a loopback device, on /dev/loop5 (for example):

# modprobe loop
# losetup /dev/loop5 /media/Backup/backup.img

Install gparted and slap a partition table on it (e.g. "msdos") and a filesystem (e.g. "ext4"):

# pacman -S gparted
# gparted /dev/loop5

Tip: If you want, you can add however many partitions you want: home, boot, var, tmp, whatever floats your boat. Of course, it will add a layer of complexity, but it's doable. The point is that you don't necessarily need another container.

Adjust the fstab

Disable any Xorg-related files

Having an nvidia, nouveau, radeon, intel, etc., entry in the Device section from one of the Xorg configuration files will inhibit it, since you will be using emulated hardware (including the video card). So it's recommended that you move/rename or delete the following:

Re-generate the initramfs image

Because the hardware has changed, while you're still in the chroot, re-generate the initramfs image and do a proper shutdown:

# mkinitcpio -p linux
# poweroff

Finally, pull out the LiveCD (the ISO file) and start the virtual machine.

Note: At this point you may notice that you no longer have a wallpaper. Don't worry about it. It's most likely because it is located on a different partition mounted in /media or /mnt, folders which were excluded from the transfer.

It most likely means that you didn't run poweroff like you were instructed to, and closed the VM with the "close" button, which is the equivalent of a power outage. Now you need to regenerate your initramfs image. To do that, you can start the VM using the Fallback entry. If you don't have a Fallback entry, press Template:Keypress (for Syslinux) or Template:Keypress (for GRUB) and rename it initramfs-linux-fallback.img.

After it boots, open up a terminal and run:

# mkinitcpio -p linux
# poweroff

"Missing operating system. FATAL: INT18: BOOT FAILURE"

You will need to install (reinstall) a bootloader. See the instructions from the Beginners' Guide.

Also, check the boot order from the BIOS or from the VM's settings. Make sure that the drive containing the install boots first.

I'm asked for the root password, for maintenance

:: Checking Filesystems [BUSY]
fsck.ext4: Unable to resolve '...'

This means that you forgot to add the drive's UUID, label or device name in /etc/fstab. The UUID is different every time you format it (or in this case, create one from scratch), and they likely do not match. Check with blkid.