I decided once again that it is time to give XEN a try. I decided to try it on a newer Athlon 64 X2 with virtualisation capabilities. That latter is important, as my overall intention is to also try OSes that are “incompatible” with XEN. I know that there are other alternatives but I’ll write on “why XEN” some other time.

Installation was easy. I am running Gentoo, so installing the xen and xen-tools packages is all I had to do in respect to userland. The “hvm” use flag was important to add support for hardware virtualization apparently. Next up was the kernel. Since all xen-sources packages were marked as unstable, I decided to try out the newest one in the package tree — 2.6.22.

I copied my .config from my current vanilla 2.6.24.2 kernel and ran “make oldconfig”. There were many, many options to configure, mainly because the newer kernels had renamed plenty. To make the long story short, I compiled everything XEN related as modules and restarted.

It kept giving me some errors I don’t even remember now, but the overall result is that the package was pulled from the tree a day after it was added for “it was buggier than [Michael Marineau] thought”. Great timing, me! I thus redid the operation with with whatever upstream considers stable, which is 2.6.18. I also had a choice of 2.6.20 and 2.6.21 but that was enough unstable stuff for one day. Get it running first, upgrade later.

First problem I had was that I did not see 3 out of my 4 hard drives anywhere (the system did boot but some important partitions were missing). I have a SATA disk, another disk connected to the on-board PATA controller, and another couple of disks on a separate Promise TX-100 (PATA) controller. In my vanilla kernel, however, I had disabled ordinary IDE disk support since libata had drivers for my PATA controllers as well and could go without them. One of the drawbacks of XEN is that you are stuck with ancient kernels. Reboot, recompile kernel with more options, reboot.

Everything seems to be fine. Oh, my binary nvidia drivers are not working. Spend some time fiddling until figuring out that they are broken two-fold. One, their build system cannot detect my kernel configuration (which is what I was trying to work around) but more importantly, two, if they did, they would tell me that after all, a xen-enabled kernel is not supported. Ah, screw them. I don’t need them anyway.

Next up, vmware-modules was not loading. An oversight on my side. Rebuild the package, vmware-config.pl, all good. Run vmware to test, power up a virtual machine and…
You are running VMware Workstation via the Xen hypervisor which is known to be incompatible with VMware Workstation. You may not power on a virtual machine until this hypervisor is disabled.. Ooooh, screw you, TOO! I don’t need you either! Just wait until I get XEN working and you’ll see!

So, what’s next. Check the configuration files in /etc/xen. I have several snapshots in vmware so my vmware disks are not exactly pretty but there is a way around it.

vmware-vdiskmanager -r hd0-000009.vmdk -t 0 /tmp/xp.vmdk

Putting the result on a separate disk speeds up the process quite a bit (/tmp is on a different disk). Next up, convert the vmware image to a xen-compatible one (that would be qemu compatible one).

qemu-img convert -f vmdk /tmp/xp.vmdk -O raw /mnt/tmp/xp.img

Good. Copy xmexample.hvm to conf/myxp and do some editing. Or create a new one:

kernel = "/usr/lib64/xen/boot/hvmloader"
builder='hvm'
memory = 128
name = "xp"
vif = [ 'type=ioemu, bridge=xenbr0' ]
disk = [ 'file:/mnt/tmp/winxp-money.img,hda,w' ]
device_model = '/usr/lib64/xen/bin/qemu-dm'
sdl=0
vnc=1
vncdisplay=11
stdvga=0
serial='pty'

Oops, run the xend daemon.

/etc/init.d/xend start

Now create the virtual machine and start it:

xm -c /etc/xen/conf/myxp

….

And it started giving me weird errors again… but that’s homework for another time.