The process for converting a VMWare VMDK disk image to Xen HVM is rather quite easy. However, there are "gotchas" that you need to consider when doing this conversion.

First, and most importantly, identify if this is a SCSI or an IDE virtual disk. If you installed Windows to a SCSI disk under VMWare, it is unlikely that Windows has the IDE drivers appropriate for Xen HVM. To remedy this, you need to follow the guide documented by Microsoft kb314082.

Once you have ensured that your windows image has IDE drivers installed, you can procede to converting the image.

Next, you need "vmware-vdiskmanager", to convert newer VMWare VMDK files into a compatible format for furthe processing. This tool comes with VMWare 5.0 and VMWare Server 1.0. There is a similar (but different) method of doing this under VMWare ESX.

Identify the appropriate vmdk file to use that represents your disk. This will either be:

1. The lone .vmdk file that is rather tiny and contains a numer of lines of text describing the geometry and component series of files that comprise the whole .vmdk.
2. The first .vmdk file in a series of 2G segmented files named with trailing -0001 style numbering,
3. The last "snapshot" .vmdk file in a series (again, named with trailing -00001 style named files).
4. The latest "REDO" .vmdk file in a series of snapshots.

I'm sure there are more incarnations of this. It's rather hairy if you've not dealt with it before.

How do you find the right one? Look inside your ".vmx" file for a line beginning with:

scsi0:0.fileName = windows2003.vmdk

or

ide0:0.fileName = windows2003.vmdk

That's all there is to it. Now, lets assume the name of our disk is "windows2003.vmdk".

$ vmware-vdiskmanager -r windows2003.vmdk -t 0 windows2003-flattened.vmdk

This will create a "single growable virtual disk" that is flattened into a single file.

The next step is to turn this flattend.vmdk file into a disk image with qemu-img from the QEMU project.

$ qemu-img convert windows-2003-flattened.vmdk windows2003.img

When this completes, you will now have a windows2003.img file that might boot for you.

The unfortunate reality of running a Windows OS is that it makes a number of assumptions at install time as to your PC hardware. If you transplant the image, you may need to change the Hardware Abstraction Layer (HAL).

Windows 2003, for example has 6 HALs:

HALMACPI.DLL - ACPI Multi processor PC
HALAACPI.DLL - ACPI Uniprocessor PC
HALACPI.DLL - Advanced Configuration and PowerInterface (ACPI)
HALMPS.DLL - MPS Multiprocessor PC
HALAPIC.DLL - MPS Uniprocessor PC
HAL.DLL - Standard PC

Only one is selected and installed as \WINDOWS\SYSTEM32\HAL.DLL at install time.

It is possible to modify your C:\boot.ini to specify a different "/HAL=HAL.DLL", if you copy in the other DLLs so they can be referenced. In this way, it is possible to do some trial and error to see which of the above HALs work with which domU HVM configuration.

When you create your Xen configuration file, you have the opportunity to set four flags that critically interact with the above HALs, namely:

# enable/disable HVM guest PAE, default=0 (disabled)
pae=0

# enable/disable HVM guest ACPI, default=0 (disabled)
acpi=0

# enable/disable HVM guest APIC, default=0 (disabled)
apic=0

# The number of CPUs to assign to this domU
vcpus=1

The above configuration would be most at home with the "Standard PC" HAL.DLL.

For the MPS HALs, one would assume you would enable APIC.

For the ACPI HALs, one would assume you would enable ACPI.

Good luck figuring out which Xen configuration matches which HAL. At the moment, the only success I've really had with Xen 3.0.3's HVM is to use the "Standard PC" HAL.DLL.

When VMWare was used to build the Windows image, it detected ACPI and used an ACPI HAL. To revert this to the "Standard PC" HAL.DLL, I had to mount the image and replace this file:

# mount -o loop,offset=$((63*512)),rw windows2003.img /mnt
# find /mnt -name 'hal*.dll' -print
/mnt/WINDOWS/ServicePackFiles/i386/halaacpi.dll
/mnt/WINDOWS/ServicePackFiles/i386/hal.dll
/mnt/WINDOWS/ServicePackFiles/i386/halacpi.dll
/mnt/WINDOWS/ServicePackFiles/i386/halapic.dll
/mnt/WINDOWS/ServicePackFiles/i386/halmacpi.dll
/mnt/WINDOWS/ServicePackFiles/i386/halmps.dll
/mnt/WINDOWS/system32/hal.dll
# cp -f /mnt/WINDOWS/ServicePackFiles/i386/hal.dll /mnt/WINDOWS/system32/hal.dll
# umount /mnt

Now that you have a "fixed" img file representing the entire drive, you can dd it straight to a lvm logical volume to be used as a Xen phy: vbd device:

# ls -la win2003.img
-rw-r--r--  1 root root 8589934592 2006-11-16 13:44 win2003.img
# lvcreate -L 8G -n win2003-hda vg
# dd if=windows2000.img of=/dev/vg/win2003-hda bs=1M

Now you are done. Start up your spiffy new HVM domain.

This, in a nutshell, is how you convert a VMWare image into a Xen HVM disk image.

Xen HVM uses the AMD SVM (Pacifica) and Intel VTX (Vanderpool) hardware CPU virtualization.

Both Parallels and VMWare now utilize the same VTX technologies in their products. Based on blogs I have read, VMWare added VTX support somewhere around or just before VMWare Workstation 5.5, and Parallels has supported Core-Duo Intel Macs since their beginning. No, I don't know if either supports AMD's SVM quite yet.

Aside from these products, I am currently unaware of anything else that use today's modern CPU SVM or VTX features.

VMWare Workstation and Server normally runs alongside a host OS, inserting a "vmmon" driver into Ring0. VMWare ESX has its own hypervisor, much like Xen, though you do need to embrace RedHat for their management harness. Hardware is emulated virtually in software (IDE, SCSI via Buslogic/LSI, Network via Pcnet32/VMX, etc). Guest OSes talk to these drivers as if they were running on a physical machine.

Xen is a small hypervisor that "paravirtualizes" CPU scheduling and assigns hardware resources to virtual "domains". The first domain, dom0, is responsible for talking to your PC's hardware directly. Each "guest" domain, or domU, can only talk directly to hardware if it has been configured to allow such access. Typically, a domU only has "frontend" drivers that talk to resources exposed by a "backend" typically from dom0. Things like virtual block devices and virtual network interfaces are handled by native Xen aware device drivers in such paravirtualized domUs.

Xen can also run in HVM mode. This means that instead of paravirtualized devices, a real set of virtual hardware is exposed to the domU to use real device drivers to talk to. Much like VMWare.

Xen initially called the HVM subsystem "VMX", but quickly abstracted it when SVM support was added. If you see mention of VMX in Xen mailing list archives, related that to the newer HVM layer.

HVM hardware is emulated via a patched QEMU "device manager" (qemu-dm) daemon running as a backend in dom0. There is no SCSI emulation, only PIIX3 IDE (with some rudimentary PIIX4 capabilities), Cirrus Logic or vanilla VGA emulated video, RTL8139 or NE2000 network emulation, PAE, and somewhat limited ACPI and APIC support. Basically the same devices available in QEMU 0.8.2 today (with a number of patches for performance, etc).

For our initial deployment, we are testing a number of AMDX2 capable motherborards. Only the AM2 and F socket based dies appear to offer SVM.

My next post will detail the conversion process for migrating VMWare images to HVM.