If you are testing Xen in your environment, you probably already have images native to other hypervisors which you might like to test. So a common question is, “How can I convert these images so I can use them in Xen?”
Conversion requires two steps: first, convert the foreign hypervisor image to a Xen-native format, and, second, adjust the contents of the image to accept the new virtual machine environment.
The second step depends largely on the guest operating system involved. Windows, for example, can require a number of steps to backup the registry, introduce the new virtual hardware, and install the new device drivers. The first step, on the other hand, is often straightforward.
Xen supports a number of storage options involving a few disk formats. Xen can easily use disk images in RAW, QCOW2, or VHD format, but one of the best combinations is a RAW image in an LVM volume. Using the LVM (Linux Volume Manager) brings a number of benefits, including a simple backup strategy. But using a RAW image in an LVM volume adds a performance boost above that of an image stored in a local file.
Other hypervisors use a number of formats, so it is likely that you will need to convert your image from a different hypervisor into a RAW format. Thankfully, the qemu-image program can handle conversions from many different formats.
Take, for example, this simple bash script called cvt2xen.sh:
#!/bin/bash imgin="$1" imgxen="$2" # if test -z "$imgin" -o -z "$imgxen"; then echo "usage: $0 <inputfile> <xenoutputfile>"; exit; fi # getfmt="`qemu-img info $imgin | egrep format`" if test -z "$getfmt"; then echo "Cannot process this file" exit; fi # isfmt="`echo $getfmt | colrm 1 13`" if test "$isfmt" == "raw"; then echo "File is raw. No conversion needed"; exit; fi echo "File $imgin is of type $isfmt" # qemu-img convert "$imgin" -O raw "$imgxen" # echo "Output:" ls -lh "$imgxen"
Don’t forget to “chmod u+x cvt2xen.sh” the file so it can be executed. Then, just convert your old image file to Xen format by typing:
./cvt2xen.sh OLDIMAGEFILE NEWIMAGEFILE.img
For example:
$ ./cvt2xen.sh precise-server-cloudimg-amd64-disk1.qcow2 precise-server-amd64.img File precise-server-cloudimg-amd64-disk1.qcow2 is of type qcow2 Output: -rw-r--r-- 1 root root 2.0G Aug 21 22:04 precise-server-amd64.img
The script employs the “qemu-img convert” subcommand to translate the old image file to a Xen RAW image.
Loading the result into an LVM volume is straightforward. I won’t give a full dissertation on using LVM here, but once you have LVM set up, you just need to create the volume and load the image into the volume.
You can create the volume with a command like:
$ lvcreate -L2G -n precise xengroup
In this case, we are creating a 2 GB volume group called “precise” in a group called “xengroup”. Then we populate the volume by transferring the image data into it using the command:
$ dd if=precise-server-amd64.img of=/dev/xengroup/precise
You will need to create a configuration file for the new image. A simple file might look like:
name = "Ubuntu-precise" memory = 512 vcpus = 1 disk = [ '/dev/xengroup/precise,raw,xvda,rw' ] serial = 'pty' vnc = 1
A detailed description of all the options in the configuration file can be found here. The options for the “disk” line particularly can be found here.
With the image itself transferred, now comes the all-important second step: getting the new image to adapt to the new hypervisor environment. Remember that the virtual environment generated by any one hypervisor will not be identical to that of another hypervisor. So a VM which was born under, say, VMware will suddenly see similar but different devices emulated under Xen. Some guest operating systems will adjust themselves to the change with little or no intervention; others may require some help.
The job of moving an image from one hypervisor to another is analogous to moving a hard drive from one physical machine to another. The operating system on the disk will have to compensate for differences in the CPU, memory, network interface, etc. Some operating systems handle this fairly easily, while others do not.
For example, a modern Linux-based image under hardware virtualization should be able to adapt itself to the new virtual hardware environment without incident. A Windows-based image, however, may require considerable manual intervention to make the adjustment.  Look into sysprep /generalize to ease the transition.  Details of moving a Windows VM can be found in posts like this one.
So, give this a try using a Linux image first. If you don’t have one handy, try one of these Debian images provided by Aurélien Jarno. Then try it with Windows (but have a good cheat sheet handy, or at least have an experienced Windows sysadmin on speed dial).
Let us know how it goes!
Was this post valuable to you? Why or why not? We’d like to run more of this type of post in the future, and we need to know if it meets your needs. Give us some feedback below.
