High Tech Sorcery

I’ve done this enough times to know it by heart but I remember when I tried to find documentation on this step I ran into countless inaccurate and outdated examples.  So here’s what I do to get the Windows GPL PV drivers installed under Xen.

1. Download the drivers from meadowcourt.org.  As of 1/18/2012 the latest version is 0.11.0.308.  You’ll need to get the appropriate drivers for your OS.
2. turn testsigning off on Windows
1. bcedit
• I like to check out the config first
2. bcdedit /set {current} testsigning on
• this turns testsigning on
3. bcdedit
• I usually run this again to make sure “testsigning Yes” appears
3. restart windows. upon restart the system should indicate it is in “Test Mode”
4. install the drivers msi file that was downloaded. I always choose “Typical” installation. I choose not to restart at this point.
5. create new default boot option
1. bcdedit /copy {current} /d “GPLPV
• this will copy the current boot setup into a new one called GPLPV
• pay attention to the id returned here
2. bcdedit /default ID
• replace ID with the id from the copy command
• this sets the new menu to be the default
3. bcdedit /set {default} loadoptions GPLPV
• this makaes this option use GPLPV drivers
4. bcdedit
• double check everything
6. restart windows

I’ve been wanting to explore the OS-level virtualization space again.  For a long time I was running linux-verser on a number of servers.  I switched to Xen because I really like the aesthetic of being able to run each virtual machine with it’s own kernel.  But I wonder if this is not too heavy a solution when all you really want is a super-chroot.  LXC has a lot of support since it’s in the kernel but it’s difficult to tell how big a community there is.  Thus far I’ve been pretty disappointed with LXC and I’ve had trouble getting information.  For example there is very little information as to whether capabilities are changed in different kernel versions.  Here are some of the major difficulties I’ve found so far:

(continue reading…)

Packages can be found here:

https://launchpad.net/~agent-8131/+archive/ppa/+packages

Design goals:

• packages created for xen 4.0.1 and xen 4.1.0
• packages mirror install of xen as closely as possible
• currently only hypervisor and utils are included (make xen and make tools)
• no rc.d scripts setup, that’s left to user
• should be installable and functional on Debian and Ubuntu and on several versions
  • Debian lenny (hopefully), squeeze
  • Ubuntu hardy (hopefully), lucid, maverick, natty

Things to work on:

• getting stubdom to compile so pvgrub is present
• testing on various systems and fixing dependencies and conflicts as needed

I’m not an expert at Debian packaging but I’ve been gotten tired of building Xen on every systems and losing the advantages that packaging brings like tracking file conflicts.  So I decided to try and package Xen though I have had no luck so far.  I am making slow but steady progress.  I wanted to package both 4.0.1 and 4.1.0 so I could compare them.  I’m finding that 4.1.0 has stability issues and switching between the two without packages is incredibly time consuming.

(continue reading…)

I took a development box running Xen 3.3 on Ubuntu 8.04 and upgraded in to Ubuntu 10.04 and installed Xen 4.1.0 from source.  I still believe Xen is the best open source virtualization solution.  At some point I’ll have to write up my experiments testing KVM + libvirt but suffice if to say the performance and stability were unacceptable.  However, while the performance of Xen is great, I have noticed some issues with Xen 4.1.0.

(continue reading…)

I’ve decided to expand this post a bit as I’ve run into a lot more problems.  I think I will try evaluating XCP 1.0.  Hard to imagine it being worse than Xen on Debian.

(continue reading…)

I’ve been feeling less than thrilled with the open source virtualization alternatives available.  It’s not that I am not grateful for all the hard work people have put into these systems.  I am increasingly finding the platforms to be buggy.  I’m trying to decide on what the best setup is moving forward.  Just thought I would jot down some of my recent notes.

(continue reading…)

With recent versions of Ubuntu running as Xen DomU’s I’ve noticed that the default scheduler is deadline.  I’ve read documentation that noop should be the preferred scheduler.  However, I make use of ionice, as do disk intensive programs such as fcheck.  It’s not often noted but ionice only works with the cfq scheduler and because of that cfq is probably the best default for any system.

I have been looking to various GNU/Linux distributions to determine their level of support for Xen.  Here’s what I found:

• Debian Etch – Xen Hypervisor 3.2.1 (via backports), Linux kernel 2.6.26 (via backports)
• Debian Lenny – Xen Hypervisor 3.2.1, Linux dom0 kernel 2.6.26
• Debian Squeeze (testing) – Xen Hypervisor 3.4.2, Linux dom0 kernel ???
• Ubuntu 8.04 (Hardy) – Xen Hypervisor 3.3.0 (via backports), Linux dom0 kernel 2.6.24
• Ubuntu 8.10-10.04 (Intrepid-Lucid) – Xen Hypervisor 3.3.0, no Linux dom0 kernel
• OpenSuse 11.2 – Xen Hypervisor 3.4.1, Linux dom0 kernel 2.6.31

As much as I like Debian and Debian based distros I think OpenSuse is probably the best platform for hosting Xen at the moment.