Running Windows as a Xen domU has several advantages, the most obvious being the ability to access Windows while running Linux. Additionally, you can take advantage of features such as domain migration, save/restore and LVM snapshots.

In this article, I’ll walk through how I converted my existing Windows XP Professional bare-metal (normal) install to a Xen guest (domU). In my setup, the Xen dom0 is running on an LVM volume on a separate physical disk from the original Windows installation. I will show you how to move the original Windows installation to a LVM logical volume. You will need a retail or volume Windows license. Xen emulates different hardware that will cause you to have to reactivate Windows. An OEM license is not allowed to move hardware. While I’d argue the physical hardware is still the same, I’m sure there is some definition that says otherwise . Finally, I converted a Windows XP installation, but the same procedure should work with any NTFS-based Windows installation (Vista, 7, Server 2003, Server 2008).

One thing before we get started: If you plan on following these directions please back up first! You’ll be partitioning volumes, copying partitions, etc. One slip of the finger and you can wipe your entire system. So be careful and back up!

Windows Disk Layout

Before we begin, let’s discuss the layout of a typical Windows hard drive. The table below shows a hard drive with a single NTFS partition.

In order to boot Windows, three conditions concerning the NTFS partition must be met:

1. The starting sector must be encoded in the partition’s volume boot sector at address 0x1c
2. The partition should not occupy the last disk cylinder. This is not always true, but in some cases occupying the last cylinder can cause a BSOD.
3. The partition must be marked bootable

Keep this in mind for now. We will see how it affects us later.

Set up Xen Virtual Block Device (VBD)

In a paravirtualized Linux guest, Xen acts as a bootloader by assigning virtual block devices and starting the kernel. In an HVM domain such as Windows we need a bootloader to start the domain. I chose to use the use the default bootloader that comes Windows XP.

Bootloaders such as Grub and the Windows bootloader are stored in the Master Boot Record of a physical disk. In order to emulate this in our Xen guest we will create a VBD that represents a physical disk.

Xen has several options for VBDs. I’m using an LVM-backed VBD as it is slightly faster than a file-based VBD and allows me to take LVM snapshots. Creating a logical volume is easy, but first we must determine what size to make it.

To meet the criteria in the previous section for booting Windows, we need to have two disk cylinders more than are required for our NTFS partition. To simplify this, just create a logical volume 25MB larger than your Windows’ NTFS partition.

Partition Logical Volume

Now we need to partition the logical volume we just created. Why do we need to partition a partition? Remember that the logical volume in dom0 represents a physical disk in domU. We need to partition this virtual disk, add a MBR and clone our NTFS volume. Luckily, everything in Linux behaves like a file so we will have no problems partitioning our logical volume.

Clone NTFS Partition

Now it is time to copy our NTFS partition. The simplest way to do this is by using dd.

This could take a while. Don’t worry if you don’t see anything, dd doesn’t display progress as it works. If you are like me and would rather know how the clone is progressing, install dcfldd and use that instead.

Modify NTFS Boot Sector

If your original NTFS partition was the first partition on the disk, you may be able to skip this step, but it won’t hurt to check.

To satisfy the first condition in the Windows Disk Layout section above, we need to make sure the starting disk sector is encoded in the NTFS boot sector of our NTFS partition. If you have followed the previous steps, your starting sector is 63. To verify this:

You will need to convert the starting address to hexadecimal and rearrange it:

1. Convert 63 to hex: 0x3F
2. Left pad with 0s so you have 8 hexadecimal digits: 0x0000003F
3. Rearrange pairs so AB CD EF GH becomes GH EF CD AB: 0x3F000000

Now using hexedit, or the binary file editor of your choice, ensure the starting sector address is inserted into the NTFS partition’s boot sector at address 0x1C (remember the NTFS partition starts at sector 63, or byte address 0x7E00).

Move to position 0x7E1C (0x7E00 + 0x001C). In hexedit this is done by pressing Enter, typing 7E1C, and pressing Enter again. Now make sure the 4 bytes at 0x7E1C equal the rearranged pairs above. If not, type the pairs. To save and exit: Ctrl+X. To exit without saving: Ctrl+C.

Fix Master Boot Record

At this point you have a virtual disk (/dev/vg/win_hda) with a single NTFS partition containing your Windows installation. Unfortunately it is not quite ready because there is no bootloader in in the MBR. We can use the fixmbr command on the Windows XP CD to install a bootloader into our virtual disk’s MBR.

First, we need to create a configuration file for our Windows Xen guest. Here is mine, YMMV:

kernel = "/usr/lib/xen/boot/hvmloader"
builder = 'hvm'

memory = 1024

name = "winxp"
vif = []

disk = [
    'phy:/dev/vg/win_hda,hda,w',
    'phy:/dev/cdrom,hdc:cdrom,r'
]

device_model = '/usr/lib/xen/bin/qemu-dm'
boot="dc"
vnc=1

Place your Windows XP CD in your CD drive. You will boot your Xen guest using this CD to access the fixmbr command.

Boot from CD:

Press any key to boot from CD

At the Welcome to Setup screen, press R to enter the recovery console:

Press R to enter the recovery console

Log on to your Windows partition:

Log in to your Windows partition

Use the fixmbr command to add the Windows bootloader to the MBR. Confirm the ominous warning message as you know what you are doing.

Running fixmbr on the Xen virtual disk

Boot Windows

At this point your Windows Xen guest domainU is ready to boot. Simply reboot the domain:

Once your Windows guest boots it should recognize new hardware and want to reboot. You will probably have to reactivate Windows at some point as well. You should probably install the Xen GPLPV drivers as soon as possible. It is probably also a good idea to remove drivers from your old hardware as they are no longer needed.

I recommend accessing your Xen guest over the Remote Desktop Protocol using rdesktop instead of over VNC. You’ll find your Windows is much more responsive over RDP.

Congratulations, you’ve ported your previous Windows installation to a Xen guest. Though it wasn’t a point-and-click migration, it’s still faster then reinstalling Windows and all of your apps from scratch.

Let me know if you found any errors or found this useful. Enjoy your new Xen setup.

In a Xen setup, the Xen hypervisor runs directly on the hardware (bare-metal). The first guest operating system (dom0) runs “on top” of Xen and has full access to the underlying hardware. Additional guests (domU) also run on top of the Xen hypervisor, but with limited access to the underlying hardware.

Converting an existing Ubuntu install to a Xen dom0 install requires installing the Xen hypervisor. In previous versions of Ubuntu this could easily be done using apt. Unfortunately no packages exist for Ubuntu 9.10 (Karmic Koala). In this post I’ll describe the steps I took to install Xen from source on Karmic. If you’d rather install via binary packages you’ll need to find a third-party repository.

Install Xen hypervisor and tools

Install Xen Kernel Sources

The stock Karmic kernel will not work when running as dom0 in Xen. You must install a new kernel. I chose to compile my own kernel. Compiling a kernel is not for the faint of heart, but isn’t as hard as you might think.

You have two main choices when it comes to a dom0 kernel. The Xen kernel or a dom0 pv-ops kernel. Normally I would recommend using a pv-ops kernel. The same pv-ops kernel can run on bare-metal or under the Xen hypervisor. The pv-ops kernel is going to be the default in future versions of Xen and will most likely be included in the mainline Linux kernel soon.

Unfortunately, the pv-ops kernel will not work with binary graphics drivers provided by Nvidia. Since I have an Nvidia graphics card (and want to use the binary drivers) I need to use the standard Xen kernel. The standard Xen kernel is still version 2.6.18, however luckily Andrew Lyon maintains forward ported patches for Gentoo that we can use on our Ubuntu install.

First things first, let’s get the kernel sources downloaded and patched:

At this point I like to modify the kernel’s “extra version” to clearly identify that this is a dom0 kernel. To do this, modify the Makefile using your favorite text editor and change the EXTRAVERSION line to look like:

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 31
EXTRAVERSION = .8-xen0-amd64
NAME = Man-Eating Seals of Antiquity
...

Compile Xen Kernel

Configuring your kernel is left as an exercise for the reader. There is a ton of existing documentation on how to do this. The easiest way to get started is to copy the configuration from the stock Ubuntu kernel and run make menuconfig.

There are some options that you want to be sure you enable:

Processor type and features --->
  [*] Enable Xen compatible kernel
Networking support --->
  Networking options --->
    <*> 802.1d Ethernet Bridging
Device Drivers --->
  XEN --->
    [*] Privileged Guest (domain 0)
    <M> Backend driver support
    <M>   Block-device backend driver
    <M>   Block-device tap backend driver
    <M>   Block-device tap backend driver 2
    <M>   Network-device backend driver
    <M>   PCI-device backend driver
    <M>   SCSI backend driver
    <M>   USB backend driver
    <*> Block-device frontend driver
    <*> Network-device frontend driver
    <M> SCSI frontend driver
    <M> USB frontend driver
    <*> Framebuffer-device frontend driver
    <*>   Keyboard-device frontend driver
    [*] Disable serial port drivers
    <*> Export Xen attributes in sysfs
        Xen version compatibility (3.3.0 and later) --->
           3.3.0 and later

Now compile and install your kernel:

If you compiled the Xen net, block and usb backend drivers as modules, you will probably want to load them by default by adding them to your /etc/modules file:

# /etc/modules
...
# These modules are required for Xen DomUs to work
netbk
blkbk
usbbk

Update Grub

Most existing Xen documentation on the web refers to the first version of Grub. Ubuntu 9.10 ships with Grub 2. Grub 2 works great with Xen, unless you use fakeraid. If you use fakeraid, I would suggest downgrading to Grub 1.

Ubuntu’s update-grub command won’t recognize your new Xen kernel, but you can easily modify the /etc/grub.d/40_custom script to manually insert it into your Grub configuration. Here’s what my 40_custom file looks like:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Ubuntu, Xen 3.4.2 dom0 2.6.31.8-xen0-amd64" {
   set quiet=1
   insmod raid
   insmod mdraid
   insmod ext2
   set root=(md1)
   search --no-floppy --fs-uuid --set 31d4873b-fed1-49d9-b37d-89d9f7a46566
   multiboot (md1)/xen-3.4.2.gz vga=gfx-1440x900x32 quiet
   module (md1)/vmlinuz-2.6.31.8-xen0-amd64 root=/dev/mapper/vg0-root root=/dev/mapper/vg0-root ro quiet splash
   module (md1)/initrd.img-2.6.31.8-xen0-amd64
}

You will need to adjust this for your system. You can use the blkid command to get the UUID for your disk partitions. You might notice that I passed the root= parameter twice on the module line. This may be a bug somewhere in Xen or Grub but I could not get anything to work when only including this parameter once.

You also need to update your default operating system. You may want to wait until after you’ve verified everything works, but eventually you should edit /etc/default/grub. Mine looks like:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.

GRUB_DEFAULT="Ubuntu, Xen 3.4.2 dom0 2.6.31.8-xen0-amd64"
#GRUB_DEFAULT="0"
#GRUB_HIDDEN_TIMEOUT=1
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT="3"
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

# The resolution used on graphical terminal
GRUB_GFXMODE=1440x900x32

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entrys
#GRUB_DISABLE_LINUX_RECOVERY="true"

GRUB_DISABLE_OS_PROBER=true

Now run update-grub:

Reboot

Cross your fingers, it’s time to reboot into the Xen hypervisor and your new Xen kernel. If you are lucky everything will work and you’ll soon be back to your desktop. You may run into driver issues, in which case you’ll need to boot your original kernel and try your hand at reconfiguring and recompiling your kernel.

If you use Nvidia or ATI binary drivers they won’t work with the Xen kernel (yet). Enabling these is a subject for another day, but it can be done. For now, let’s stay focused on getting Xen fully installed and running.

After rebooting, you can check a couple of things:

Start Xen tools

Once you are running the Xen hypervisor and a Xen compatible dom0 kernel, you need to start the Xen daemon. This is done with:

You can start this automatically by establishing sysvinit links with:

If you want Xen domUs in /etc/xen/auto to start automatically on boot, set the xendomains init script to run on boot:

Compile a domU kernel

This step is optional. You may want to compile a kernel for use by your Linux domUs. Many distributions can run as a domU with their stock kernel however if that doesn’t work you can configure them to use a Xen domU kernel.

Configuring a Xen domU kernel is similar to configuring a Xen dom0 kernel:

When configuring the domU kernel, you’ll want to make sure you enable:

Processor type and features --->
  [*] Paravirtualized guest support --->
    [*] Xen guest support
Device drivers --->
  [*] Xen /dev/xen/evtchn device
  <*> Xen filesystem
  [*] Create xen entries under /sys/hypervisor

Ready for domUs

Congratulations, your Ubuntu 9.10 Karmic Koala installation is now running as a domain 0 on top of the latest Xen hypervisor. You are ready to start installing domUs.