We have made a solution that has been tested on several machines. It works great. But it isnt that easy.

http://sirping.kafit.se/wp/index.php/category/kvm/

Hi Louise, I just did a writeup of how to do this at http://opensource.is/samfelag/greinar/tommi/53-xen2kvmvm, it mostly goes through configuration of the guest OS and not the actual hypervisor host itself.

The work on the hypervisor is not so hard just watch out that when you import the machine, man virt-install, look for --import that you choose bus=virtio for the disk.

Hi Tomas,

Very cool howto you have written there!

But I don't quite understand what I have to do on the host.


virt-install --import test.img


?

We've developed an in-house method to do migrations, it is done in a sort of "by hand" fashion, but the extra-work pays great because you can migrate any given machine (only Linux at this time) to any other machine, virtual, physical, even with different Hardware layout and/or Filesystem options, it even allows me not to turn off the migration candidate, very cool! It has been a savior for us at work. I'm moving from VMware and XEN to KVM.

Here is the recipee:

NOTE: The method is sort of a donor-recipient when doing organ transplants and make sure that the "recipient" you will prepare is in the SAME OS level and flavor (or at least very close). ALSO make sure to MOVE the /etc directory/partition to another name (maybe /etc.bak) on the directory structure of the mounted partition, this will become handy later.

1. Prepare the receptor: Create a virtual machine on the platform of your preference that can accommodate the machine you are going to migrate over. Just ONE partition is crucial which is /boot, other than that, you can create a completely different FS layout at your heart's content, just as the "donor-recipient" scenario suggests, make sure you allocate enough disk space for the transplant otherwise you'll have to repeat the process, say if you want to consolidate 2 partitions /dev/sda2 and /dev/sda3 that holds the /var and /opt FSs, into one, that's fine, as long as you have enough space declared. If the migrations take place in VIRTUAL disks, you shouldn't you worry about partitioning too much except for other criteria other than performance, I do my clonings often with 2 partitions, / and /boot. You don't have to worry to install ANY packages for the receptor, actually the only one needed is all included in /boot.

2. Once you have your "receptor" with the same OS and have the partitions /boot and others ready, let's do the cloning, for those who need partitioning, you will have to clone and consolidate partitions one by one, say you created /var in /dev/sda4 and you have it living under / in the "donor" server, you will have to perform this action for each destination partition and exclude everything else.

3. Cloning: START you newly made receptor server in maintenance mode with Knoppix, you may prefer other "rescue" disks, but I've found Knoppix very handy, it recognizes LVM, and ext4, I think raiserfs but I haven't tried that one. Make sure to become root under knoppix and then go to /mnt directory, you will see that Knoppix will find all the partitions of the recipient server, but will not mount them just yet, you will have to mount each partition in each mounting point by hand, if you do it in the GUI it sometimes mounts them as READ-ONLY, we need them to be WRITABLE. After mounting (or before) assign an IP on your Knoppix server that can reach your donor server, ping it or SSH to it to make sure that access is available through SSH. NOW, here's the magic words from the receptor that will clone a server that has 2 partitions mainly /boot and /; let's assume that we created 2 partitions also in the receptor server /dev/sda1 as the /boot partition and /dev/sda3 as the / partition, I change to the /dev/sda3 partition which is where I'll be cloning the server to:

ssh IP.of.the.donor 'cd /;tar --exclude ./proc --exclude ./sys --exclude ./boot --exclude ./dev --exclude ./initrd -cpf - ' | tar xvpf -

(Mind the apostrophes and the spaces please)

In simple english, what we have done with this is: copy all the contents AS files from the old server preserving permissions and all inode characteristics into the new server.

NOTE: VERY VERY important! Since we have moved also the /etc directory, bear in mind that we've copied essential configuration files that can break the server, 1. THE network card definition and 2. The FSTAB and MTAB entries, although only FSTAB is truly essential.

4. After copying all contents from the "donor" server, you have to replace (maybe create a backup first) of the donor's /etc/fstab in the new /etc directory you just copied, you have to replace it from the /etc.bak directory that you made previously, this will map any prepare the "new" clone to boot up with the correct partitioning flags that you have done in the receptor-server.

5. That's IT! Reboot your cloned machine, retire your Knoppix rescue disk and enjoy your cloned server. In my experience most of the servers take less than 20 minutes to be cloned completely with this process of course if you're cloning DBs or other huge FSs use your criteria and special considerations, but this cloning method works every time p2v v2v v2p or p2p. If you experience trouble, please DO let me know and I'll be happy to respond any question or doubt.