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

• Isolation – The LXC home page mentions isolation repeatedly, as does the README.  I was disappointed to find running dmesg on my container displayed the messages from the host system.  That’s not isolated enough for me.
• Networking – While you can assign multiple ip addresses you can only have 1 interface which is on 1 bridge.  With Xen I have several virtual machines with multiple devices, usually one on a public bridge and another on a vpn.  Also on Ubuntu guests since udev does not work the network/interfaces file is not run and there is not routing until ifup -a is run from the guest.
• No udev – This could be ok except for ubuntu guests which, as noted above, use upstart which depends on udev notifications to start networking and other services.  Basically it’s safe to assume that with an ubuntu guest many services will not be started.  This will not be the case for guests using sysvinit or systemd as far as I know.

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

• Xen 4.0.1
  • linker error: /usr/bin/ld: cannot find -lxenctrl
    • /usr/bin/ld: cannot find -lxenctrl
    • [Pkg-xen-devel] Trying to compile/pack the Xen 4 for Debian fail…
    • [Xen-devel] Trying to compile Xen 4 for a Debian package fail – Xen Source
    • use this patch: [Xen-devel] Compile error for xen-4.0.1 if xen-tools is not inst – Xen Source
• Xen 4.1.0
  • ipxe – requires package for ipxe
• common:
  • linker error: ld: unrecognized option ‘-Wl,-Bsymbolic-functions’
    • [Xen-devel] XEN build failure – Xen Source
    • [bug-recutils] recfix tests fail on Ubuntu 64-Bit systems
    • fix: Re: [bug-recutils] recfix tests fail on Ubuntu 64-Bit systems
• packaging help:
  • How To Create A .DEB Package [Ubuntu / Debian] ~ Web Upd8: Ubuntu / Linux blog
  • How do I patch a Debian package
  • Packaging/PPA/BuildingASourcePackage – Launchpad Help

• rebooting from inside a DomU causes it to be destroyed.  This may be a problem with xl or with pygrub but I get the following error when rebooting: “failed to run bootloader: -3″
• confusion over xl/xm and xencommons/xend.  I’ve learned that I should run xencommons and use xl and not use xend and xm.  Running both xend and xencommons seemed to lead to stability issues.  Using xm was useless as my existing configurations would not work (problems with blktap2 and qcow2).  However xl worked fine as long as I removed any python code from the config files.
• pvgrub does not work.  While pvgrub seems like a much better alternative to pygrub I found that it would give me an error about the disk not being available.  This may just require a change to grub but that’s not ideal.  I want a drop-in secure replacement for pygrub.
• configuring the Dom0 kernel takes time.  You have to be somewhat careful on the options and there is extremely little documentation on the various Xen options.  I found that “CONFIG_XEN_DEV_EVTCHN=y” was better than a module since you need evtchn on the Dom0 always.
• problems with xenpm. running “xenpm get-cpufreq-states” led to an unkillable hung process and shortly thereafter a system lockup. See: xenpm bugs.

Helpful information:

• Xen 4.1 on Ubuntu 10.04 64bit » ZeroAccess (helpful info on compiling Xen 4.1.0 and a Dom0 kernel)
• Performance difference between Xen versions | Xen | Devel (information on performance and power saving)
• xenpm – Xen Wiki
• PvGrub – Xen Wiki
• PyGrub – Xen Wiki

Sadly a person installing Xem 4.0.1 on a freshly installed Debian 6.0 install is in for some trouble getting Xen to work.  You’ll see errors about hotplug scripts not working related to the tap driver.  The problem stems from Debian Bug #591456.  The solution is to create /etc/xen/scripts/hotplugpath.sh with the following contents:


SBINDIR="/usr/sbin"
BINDIR="/usr/bin"
LIBEXEC="/usr/lib/xen/bin"
LIBDIR="/usr/lib64"
SHAREDIR="/usr/share"
PRIVATE_BINDIR="/usr/lib64/xen/bin"
XENFIRMWAREDIR="/usr/lib/xen/boot"
XEN_CONFIG_DIR="/etc/xen"
XEN_SCRIPT_DIR="/etc/xen/scripts"


It’s also important to note that Debian stripped out the blktap2 module so only the blktap module is available in Debian 6.0 currently.  I’d follow Debian Bug #586772 to see if it ever gets re-added.  More likely blktap2 may be added through a backport at some point.

Next you might want to fix an error in /etc/xen/scripts/xen-hotplug-cleanup.  You can change line 24 from:

if [ $(xenstore-read "$vm_dev" 2>/dev/null) != "" ] \

to:

if [ "$(xenstore-read '$vm_dev' 2>/dev/null)" != "" ] \

Alternatives not guaranteed to work:

• [Bug 605182] New: /etc/xen/scripts/xen-hotplug-cleanup: line 24: [: !=:
• [Xen-devel] [PATCH] bug fix for “xen-hotplug-cleanup” script – Xen Source

Other bugs and problems:

• no pv_grub is present
• block-attach and block-detach in dom0 seem to not work – attach doesn’t seem to give a usable disk and detach fails unless the –force option is used
• domu’s do not have there xenstore entries cleaned up after shutting down (this may be fixed by patching xen-hotplug-cleanup)

All in all I’d say Xen 4.0.1 in Debian 6.0 is a mess.  Not sure if this is a buggy Xen release or related to Debian changes.  But I’d advise a lot of caution and testing before implementing a Xen server using Debian 6.0.

Xen

As someone that prefers Debian and Debian-based distros using Xen means using Debian.  However the Xen 4.0.1 packages in Debian Squeeze have seemed buggy to me, partcularly when allocating large amounts of memory to a DomU.  In addition for the purpose of running a Windows server there are no signed paravirtualization drivers available.  This leaves people in the position of choosing lower performance or the hassle of unsigned drivers.  Those drivers can be found at http://www.meadowcourt.org/downloads/.  The Xen team has had some recent success getting  parts of the dom0 kernel code merged.  If the entire

KVM

I have generally believed that KVM would overtake Xen given the level of development activity.  Yet, in my dealings with KVM I still find it has a long way to go.  I find bugs with virtual machines using SMP (performance problems, lockups on AMD processors) and even keeping a correct clock for Windows systems.  There are signed Windows drivers but the virtio net drivers are too buggy for production use (as of version 1.1.6).  You can get those drivers here: http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/.  KVM is so well supported that there are many OS options: Debian, Ubuntu, Proxmox.

OpenVZ / LXC

I used linux-vservers for quite some time before switching to Xen.  Container-based virtualization is seeming better to me now in that performance should be close to native, particularly with regard to latency.  I also think I overlooked the value of container-based virtualization with regard to ease of management tasks such as backup or migration.  I haven’t used OpenVZ or LXC.  Using Proxmox to administer OpenVZ seems like it might be a pretty easy way to go.  OpenVZ can also be used from Debian.

• OS
  • Debian 6 – Xen, KVM, OpenVZ
  • Ubuntu 10.04 – KVM
  • Proxmox – KVM, OpenVZ
• Xen
  • - unsigned paravirtualization drivers
  • - buggy with large memory
• KVM
  • + signed paravirtualization drivers
  • - buggy paravirtualization nic driver
  • - clock issues
  • - SMP issues
  • + ksmd may offer more memory for virtual servers
• OpenVZ
  • untested
• LXC
  • untested

• 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.