Levitation in Virtual world or how to convert Xen images to KVM

Levitation in Virtual world or how to convert Xen images to KVM

The rule of the "cloud" has already been established and now we have multiple vendors fighting for market share. Many companies started relying on the cloud and seeking more and more automation and could services. It looks easy, you just select a cloud provider, use it's services and you have several virtual machines or containers within minutes. Sounds like magic? Well, Here is the question you are probably asking yourself . What is behind it all? The answer is;  good old virtualization, strong APIs and scripting. 
  I guess most of you, who are to some extent already familiar with vitualization, and have the affinity to work with opensource technologies have used Xen. It was the very first in the opensource world, and that is for sure. Its first release was in 2002 and it definitely became one of the dominant virtualization solutions in the opensource world. If we take a look at the main vendors like Oracle for example, we will see that behind OVM is again Xen. At the same time lots of companies started using another solution, which you might have heard of - Citrix. The company that created it became very well known.  

  KVM was released in 2007 by an Israeli software developer and soon the company was acquired by Red Hat. Soon after the acquisition, the company dropped it's support for Xen and started supporting KVM in its kernel. Lots of projects started using KVM and benchmarks show that performance of Linux guests is better than that in Xen.

  Here the story ends and action begins. The ITGix managed services team has an extensive experience in Openstack and migrations of other platforms. We had a case where we had to migrate Xen images to KVM as a default hypervisor. Sometimes it is not just the simple case where you have to spin up several virtual machines and install the software on top of it. Unfortunately, the Xen hypervisor image was sent without a partition table and that was a difficult issue to fix. 

 Here is how we managed to solve that problem. Once you get the images, you have to install the following tools:

Guestfish – command-line that will help you modify the image
virt-v2v - KVM tool that converts from foreign hypervisor to run KVM 
For our example we already have an image transferred in qcow2 format: xen-image.qcow2
working-station: qemu-imga size xen-image.qcow2
working-station: 100G
#Add a block device or virtual machine image to the shell
working-station: guestfish -a xen-image.qcow2
><fs> sparse output.img 101G    
 # adjust the output size based on qemu-img info XXX.qcow2 command output, it should be greater than the virt. disk size
><fs> run
# Create a partition table on the output disk:
><fs> part-init /dev/sdb mbr
><fs> part-add /dev/sdb p 2048 -2048
# Copy the data to the target partition:
><fs> copy-device-to-device /dev/sda /dev/sdb1 sparse:true
# Optionally resize the target filesystem. Use ntfsresize
# for Windows guests:
## ><fs> resize2fs /dev/sdb1
Next step is to use the guestfish to change the boot configuration
mount again in output.img
working-station: guestfish -a output.img -m /dev/sda1
vi /boot/grub/grub.conf 
Amend the proper device for boot. Next step is to run virt-v2v and transform the machine to KVM bootable.
working-station: virt-v2v -v -x -i disk output.img -o local -os ./
Use glance to import the machine and start it.