Linux-KVM: Migrating Hyper-V VHD Images to KVM

March 23rd, 2011 | Tags: , , , ,

I have always been a big fan of Hyper-V, and was actually a Virtualization MVP 2 years in a row.  However recently I haven’t been able to get past the really poor support for Linux on the Hyper-V platform.  We run a large number of hypervisors in our international sales offices (15+) and have a need to run both Linux and Windows on them.  This has necessitated our switch to Linux-KVM as their Windows support is far better than Hyper-V’s Linux support.  As such with an upcoming trip planned to our European offices I have been planning exactly how our migration will look, of course the first iteration of this plan consisted of me deploying replacement VMs on the KVM stack then migrating to the VMs individually.  Though this plan was lengthy and cumbersome it would work.

Thus it was time to set out on a journey of laziness.  I started by investigating physical to virtual conversion utilities and unfortunately KVM doesn’t seem to have a lot of value in this area.  So I started looking at some more basic methods of accomplishing my task.  Enter kvm-img (also called qemu-img) this is basic disk management utility that you will use to create image files, monitor their growth, snapshot, basically anything to do with managing a disk image…  Including converting from one format to another.  Wait, what formats?

raw – The most simple file format and can be mounted locally

qcow2 – The most versatile file format supporting layered images, encryption, compression, and snapshots although there seems to be some performance issues

vdi – Virtualbox 1.1 compatible image format

vmdk – VMWare 3 and 4 compatible image format

vpc – VirtualPC compatible image format

I left out some formats which aren’t terribly useful, for more information see the man pages.  Now lets review VirtualPC and Virtual Server were the precursors to Hyper-V.  However with the advent of Hyper-V we lost the compatibility of VMs between Hyper-V and Virtual PC.  Or did we?  It was true that you could not take a Hyper-V VM with the Integration Services installed and run it on Virtual PC.  Though the issue was never the VHD format.  That specification remained the same.  The actual issue was that when you installed the Hyper-V Integration Services it forced the install of an APIC HAL, and since Virtual PC did not support an APIC HAL it would fail to boot.  Now since Hyper-V does support APIC this should not be a problem.  Assuming that we can successfully convert it.

Conversion Command from VHD to a Raw Image

# kvm-img convert -f vpc -O raw /kvm/images/disk/disk.vhd /kvm/images/disk/disk.img

Above you will see the -f option indicates the format of the source image and the -O (capital “o”) then followed by the path to the source file and the path to the output file.

I was able to successfully convert a Windows 2003 Server amd64 as well as Windows 2008 R2 Standard.  Once converted I was able to create a VM and boot it straight away.  On the Windows 2003 VM I needed to uninstall the Integration Components, though 2008 R2 includes them in the kernel so it was not necessary to uninstall them.

So obviously the next thing I thought of is that if kvm-img supports vpc as a file format, perhaps KVM can boot it.  Well it can.  So if you are so inclined you could simply copy the file from the Hyper-V server to the KVM server and start it (and uninstall the Integration Components if applicable) I plan on investigating the perfomance implications of this choice though that is not part of this article.

Also please keep in mind that you will need to install the VirtIO drivers into your Windows VMs in order to take advantage of the VirtIO Interface of Storage and Network.  If you do this your performance is very fast.  I will most likely document this in a future article though this is fairly well documented on the Internet currently.

  1. Thomas
    April 6th, 2011 at 01:29
    Quote | #1

    Thanks for your article!

    You wrote:
    # kvm-img -f vpc -O raw /kvm/images/disk/disk.vhd /kvm/images/disk/disk.img

    but it seems that you have missed “convert” in the above command.
    In my case this works fine:

    # kvm-img convert -f vpc -O raw /kvm/images/disk/disk.vhd /kvm/images/disk/disk.img

    • matthew.mattoon
      April 6th, 2011 at 01:41
      Quote | #2

      @Thomas You are absolutely correct. Thanks for catching that.

  2. Mat
    April 6th, 2011 at 13:46
    Quote | #3

    Your argumentation to move towards KVM points similar experience with Linux on Hyper-V:

    I got to the following (temporary) conclusion:
    The hv-Modules are stil undergoing high development changes. – By giving a look at linux-next and looking at the changelog in every release of the kernel.

    Modules in mainline can work if you are lucky – they have evolved and got more stable – but they can be quite unstable too: Sometimes devices just crash, meaning that your VM looses either network oder storage connectivity which isn’t what you realy want in production.

    Modules from MS (LinuxIC 2.1) work more stable on RHEL5-based distros – actually it was the only way I could ommit crashing VMs but sometimes RHEL5-close aren’t just the right distro for your distro.

  3. matthew.mattoon
    July 21st, 2011 at 11:33
    Quote | #4

    I have found a serious bug in how KVM handles dynamic VHDs over 127GB. As a work around if you need to convert a large VHD, you can (1) convert it to fixed using MS Utilities (2) perform the conversion with vboxmanage’s clonehd option which is a Virtualbox utility which will convert it properly, although you will not end up with a dynamic raw image.

  4. matthew.mattoon
    July 21st, 2011 at 15:19
    Quote | #5

    Also important to note, that if you examine a fixed size VHD with kvm-img info file.vhd then it shows the format as “raw” so it looks like this can be sent directly into production as is (though we like to dd to an LV before we do that).

Comments are closed.