OpenWetWare:Software/Server/Virtual Machines/Xen/Converting VMWare Image to Xen

From OpenWetWare
Jump to navigationJump to search

Converting a VMWare image to Xen HVM

What's this article on OWW for?

We're always trying to make sure we're just a little bit more future-proof as we continue to grow OWW. Xen is a hypervisor that allows you to run an OS on top of the Xen Hypervisor, a sort of virtualized interface to the underlying hardware. I use VMWare Fusion on my Mac so I can run Windows XP without requiring another box. Like Xen, Fusion allows other operating systems to be run as a virtual machine. The server OS OWW currently runs on is Red Hat Enterprise Linux Version 4; we're migrating to Version 5. For testing, I can run RHEL on my computer at the same time MacOS is running. Once OWW is up and running on it, I have a disk image that can be copied to any other computer running VMWare Fusion that contains a bootable image of RHEL5 including OWW.

This article outlines the steps needed to convert the VMWare image file into a Xen-compatible image. Once this is done, the exact same image file can also be run on any server that runs Xen.

Ian Blenke

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


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:

#<nowiki/> mount -o loop,offset=$((63*512)),rw windows2003.img /mnt <nowiki>#<nowiki/> 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 <nowiki># 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.

vmware/vmdk/xen/hvm/qemu | 0 trackbacks