Migrating VMs from Xen to XenEnterprise

As a reseller, it's only normal to run the product you are reselling. The problem is that we've been running our production servers on Xen3 for the last few years and XenSource do no include a migration from Open Source Xen to their commercial offering.

So I have to make up my own.

First, some reverse engineering: XenEnterprise provides a VM export and import function. The "format" of an export is:

<VM export name>/ova.xml   (config file)
<VM export name>/<disk>/chunk-00000000<n>.gz   (disk chunks)

One of the problems you face is that each chunk is a maximum raw size of 1000000000 bytes, and then is run through gzip. Here's how you can generate your own chunks from your current block device. All of this article's commands are being done on my ORIGINATING Xen server, not the destination XenEnterprise server.

cd /tmp
mkdir myvm
cd myvm
mkdir hda3
cd hda3
dd if=/dev/gnbd/FC4 of=chunk-000000000 count=1000000 bs=1000
gzip chunk-000000000
dd if=/dev/gnbd/FC4 of=chunk-000000001 count=1000000 skip=1000000 bs=1000
gzip chunk-000000001
dd if=/dev/gnbd/FC4 of=chunk-000000002 count=1000000 skip=2000000 bs=1000
gzip chunk-000000002

and so on until you have copied your whole block device. Keep note of the raw length of that last chunk, since we will need to tell the config file the raw length of the block device we want at the other end. Another way to know the length of the block device is to do:

dd if=/dev/gnbd/FC4 of=/dev/null

and the very last line will say something like:

2306867200 bytes (2.3 GB) copied, 211.411 seconds, 10.9 MB/s

So, in my case, the block device was 2306867200 bytes in length.

Do this for each of your original VM's disks. Here's is what your directory tree will end up looking like:

# cd ..
# find ./myvm -print
./myvm
./myvm/hda3
./myvm/hda3/chunk-000000002.gz
./myvm/hda3/chunk-000000000.gz
./myvm/hda3/chunk-000000001.gz
./myvm/hda2
./myvm/hda2/chunk-000000000.gz

Now on to the config file. It is a simple XML file and just gives the receiving XenEnterprise an idea of the originating VMs disk layouts. Your config file will be called /tmp/myvm/ova.xml Here's mine:

<?xml version="1.0" ?>
<appliance version="0.1">
<vm name="vm">
<label>
MyVM
</label>
<shortdesc>
Fedora Core 4 test machine
</shortdesc>
<config mem_set="262144000" vcpus="1"/>
<hacks is_hvm="false" kernel_boot_cmdline="root=/dev/hda3 ro ">
<!--This section is temporary and will be ignored in future. Attribute is_hvm ("true" or "false") indicates whether the VM will be booted in HVM mode. In future this will be autodetected. Attribute kernel_boot_cmdline contains the kernel commandline for the case where a proper grub menu.lst is not present. In future booting shall only use pygrub.-->
</hacks>
<vbd device="hda2" function="swap" mode="w" vdi="vdi_hda2"/>
<vbd device="hda3" function="root" mode="w" vdi="vdi_hda3"/>
</vm>
<vdi name="vdi_hda2" size="134217728" source="file://hda2" type="dir-gzipped-chunks" variety="system"/>
<vdi name="vdi_hda3" size="2306867200" source="file://hda3" type="dir-gzipped-chunks" variety="system"/>
</appliance>

The mem_set is 256 megs, the function= can be anything, and I have no idea what the variety= means... Notice that source= doesn't actually match my real path. That's normal. The more observant of you will notice that I am actually migrating a swapfile as part of this import. Waste of time? Only you can say :-)

Now it is time for the actual import. To do this properly, you will need a statically linked file from the XenEnterprise server itself:

scp myxenterpriseserver:/opt/xensource/bin/xe /tmp/

You are now ready for the actual import. Nothing simpler:

/tmp/xe vm-import -u root -pw myrootpassword \
-h myxenenterpriseserver dir-name=/tmp/myvm/

The following lines tells you everything is honky-dory:

New VM uuid: 8453f105-bedd-4dbc-98fb-42b8b6605b44
Processing step 4/4 -
Import successful

You are now in good shape. Start your XenEnterprise Admin console and try to start up the new VM. If it bombs at kernel bootup, it is because the XenEnterprise guest initrd is incompatible with your VM. Don't despair, that's the subject of my next article...