Moving an existing install into (or out of) a virtual machine

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This article describes how to transfer your current Arch Linux installation in or out of a virtual environment (i.e. QEMU, VirtualBox, VMware). A virtual machine ("VM", for short) uses different hardware, which needs to be addressed by re-generating the initramfs image and possibly adjusting the fstab – especially if it is an SSD.

Moving out of a VM

Moving out of a virtual environment is relatively easy.

Set up a shared folder

Setting up a shared folder between the guest virtual machine and the host depends on the hypervisor you use. Please thus refer to their specific wiki page or manual.

If you do not already have an ext4 partition, see File systems.

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Ext2Fsd 0.66 does not support extended attributes and ACL. (Discuss in Talk:Moving an existing install into (or out of) a virtual machine)

If you are on Windows, install Ext2Fsd to be able to mount ext volumes.

Transfer the system

From the virtual machine, open a terminal and transfer the system:

# rsync -aAXHSv /* /path/to/shared/folder --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found,/home/*/.gvfs}

This can also be done with clonezilla boot disk or dd from a random Linux live-cd. If you're using Virtualbox you need to connect the target drive through USB (or SATA to USB cable) otherwise use an external USB drive to save the disk image (with dd or clonezilla).

Chroot and reinstall the bootloader

Boot a "live" GNU/Linux distribution, mount the root partition and chroot into it.

Reinstall your bootloader/boot manager: either Syslinux, GRUB or systemd-boot. Do not forget to update the configuration file: syslinux.cfg for Syslinux, grub.cfg for Grub, or the systemd-boot boot entries located in /boot/loader/entries/.

Note: You might be able to boot directly without reinstalling the boot loader. Try that before using a chroot. That way you could (possibly) reinstall the bootloader and regenerate ramfs from a graphical environment.

Adjust the fstab

Since your entire root tree has been transferred to a single partition, edit the fstab file to reflect the right partition(s).

Check with the blkid command, since lsblk is not very useful inside a chroot.

Re-generate the initramfs image

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

# mkinitcpio -p linux 

And that is about it.

You will most likely need to set up the network, since the virtual machine was probably piggybacking on the host OS's network settings. See Network configuration.

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
Tip: Using fallocate is much faster:
# fallocate -l 10GiB -o 1024 /media/Backup/backup.img

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: fdisk -l now shows a Sectors column instead Blocks. Does the same affirmation apply? (Discuss in Talk:Moving an existing install into (or out of) a virtual machine)

If you want to create one the exact size of your root partition, run fdisk -l and use the value from the Blocks column for the count= parameter. Note that you will transfer your 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

Next, partition the /dev/loop5 device by running your favourite partitioning tool. Create a partition table on it (e.g. msdos), choose the partition scheme and create the partitions. Then create a file system on the partitions, which will appear as /dev/loop5p1, /dev/loop5p2, etc.

Transfer the system

Mount the loopback device and transfer the system:

Note: If the container was saved somewhere other than /mnt or /media, do not forget to add it to the exclude list.
# mkdir /mnt/Virtual
# mount /dev/loop5p1 /mnt/Virtual
# rsync -aAXv /* /mnt/Virtual --exclude={/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found,/home/*/.gvfs}

Convert the container to a compatible format

Choose the appropriate command depending on the desired virtual machine.

To convert into a KVM container, use qemu with the following command line:

$ qemu-img convert -c -f raw -O qcow /media/backup.img /media/backup.qcow2

To convert into a VirtualBox container, use virtualbox with the following command line:

$ VBoxManage convertfromraw --format VDI /media/backup.img /media/backup.vdi

To convert into a VMware container, use virtualbox with the following command line:

$ VBoxManage convertfromraw --format VMDK /media/backup.img /media/backup.vmdk

Chroot and reinstall the bootloader

Connect the container to the VM, along with a Linux LiveCD (e.g. the latest Arch Linux ISO) in the VM's virtual CD-ROM, then start the VM and chroot into it:

# mount /dev/sda1 /mnt
# arch-chroot /mnt /bin/bash

Reinstall either Syslinux or GRUB. Do not forget to update its configuration file:

  • For Syslinux, it should be APPEND root=/dev/sda1 ro in syslinux.cfg.
  • For GRUB, it is recommended that you automatically re-generate a grub.cfg.

Adjust the fstab

Since your entire root tree has been transferred to a single partition, edit the fstab file. You may use the UUID or label if you want, but those are more useful in multi-drive, multi-partition configurations (to avoid confusions). For now, /dev/sda1 for your entire system is just fine.

/etc/fstab
tmpfs                    /tmp      tmpfs     nodev,nosuid          0   0
/dev/sda1                /         ext4      defaults,noatime      0   1

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 prevent it from starting, since you will be using emulated hardware (including the video card). So it is recommended that you move/rename or delete the following:

# mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak
# mv /etc/X11/xorg.conf.d/10-monitor /etc/X11/xorg.conf.d/10-monitor.bak

Re-generate the initramfs image

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

# mkinitcpio -p linux
# exit
# umount -R /mnt
# poweroff

Finally, pull out the LiveCD (the ISO file), so that you do not boot back into it, and start the virtual machine.

Enjoy your new virtual environment.

Troubleshooting

"mount: special device /dev/loop5p1 does not exist"

Use losetup --partscan, for example:

# losetup --partscan /dev/loop5 /media/Backup/backup.img

This should create device nodes for each partition you have created inside the loop device.

"Waiting 10 seconds for device /dev/sda1; ERROR: Unable to find root device '/dev/sda1'"

Waiting 10 seconds for device /dev/sda1 ...
ERROR: Unable to find root device '/dev/sda1'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: cannot access tty; job control turned off
[rootfs /]# _

It most likely means that you did not 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 do not have a Fallback entry, press Tab (for Syslinux) or e (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 are using a Btrfs filesystem with compression for /boot, for which Syslinux currently cannot boot from.
  • The boot order from the BIOS or from the VM's settings is not properly set up. Make sure that the drive containing the bootloader is the first one to boot.

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.