Will likely not be included in edgy. IRC log of discussion:

  • iwj: Hi.
  • iwj: What can I do for you ?
  • BenC: got some bad news, Xen is very likely not going into edgy's kernel
  • iwj: Oh dear. What's the difficulty ?
  • BenC: it's two-fold
  • BenC: first, it's based on a stock kernel, and we are neither stock, nor (2.6.17)
  • BenC: so the merge headache is bad because of various conflicts with upstream and xen
  • iwj: Urgh.
  • BenC: not to mention that after fixing all that, the kernel wont compile as non-xen without a lot of butchering to their build code
  • iwj: Oh that's very lame of them.
  • BenC: I could get it working in about a day (non-xen, not sure about a xen build)
  • iwj: That really isn't encouraging, yes.
  • BenC: but the long-term maintainability would be more than I want to take on
  • iwj: Quite so.
  • BenC: if they would setup a git tree, and actually test non-xen builds, I'd be willing to do it
  • iwj: Well, err, can you say as much as you've just said in the spec wiki page and we'll drop this for edgy.
  • BenC: ok
  • BenC: Ok, to just paste this?
  • iwj: That'll do.


Provide prebuilt Xen 3.0.2+ kernels for all currently provided x86 flavors: 386, 686, k7, server, server-bigiron.

  • Should provide the widest range of hardware support possible.
  • Should automatically update the grub menu.lst, as the other kernels do.


Xen 3.0.2 marks a significant step in the evolution of the Xen hypervisor as it drops the architecture approach taken in the past to make Xen integrate into the Linux kernel as a sub-arch of i386. Xensource have invested a considerable amount of time and effort bringing the Xen-patched kernel (XenLinux) up to mainline standards. Work continues on the subarch, focusing on integration with the mainline kernel.

As a result, the door is now open for end users to start using Xen without adversely affecting their desktop experience. Xen 3.0.2 can be configured as a modularised kernel and plays nicely with mkinitrd, mkinitramfs and other userspace tools to provide the best integration possible with existing infrastructure.

There are a few warts at the moment: Xen doesnt play nicely with device drivers that need variable length DMA masks (like ice1712) due to its internal allocator, and it doesnt presently play nice with the NVIDIA kernel module (and probably the ATI one as well).


Xen offers tremendous flexibility and performance as a hypervisor to any system administrator that requires virtualisation. We need to support it in Ubuntu so we can all reap the benefits of this amazing technology.

Use Case

  • A system administrator wants to deploy one or more physical servers partitioned into virtual machines to serve different services to his users.
  • A datacenter administrator wants to overhaul his existing virtualisation infrastructure and is looking for a well supported, well integrated way to leverage Xen.
  • A Ubuntu developer wants to test the latest development snapshot of Edgy, without hosing his workstation by upgrading.
  • The Ubuntu core team wants to perform automated testing in a virtual machine.



Need to support the Server target on the Big Three architectures. Need to support as wide a variety of systems as possible. This includes variations of memory footprints, and CPU types (NUMA).

Also need to support workstation targets.

The Grub package needs to be patched to support autoconfiguring Xen kernels.

kernel-package needs to be patched to support Xen 3.0.2 (Malone bug 40088) and kept up to date for future versions.


Ubuntu specific patches will be ported to the XenLinux 2.6.16 tree. Kernels will be built for all existing targets.

Discussion and comments

If we do this for edgy it should clearly be accompanied by inclusion of the xen hypervisor itself in main; the two tasks come together. See also XenVirtualMachine and XenUbuntu. -iwj

We should consider whether we can have the default Edgy kernels support Xen out of the box (ie, provide xen-enabled kernels) now that recent Xen allows kernels to target both i386 and Xen/i386. -iwj



UML Skas
















util-vserver, vserver-debiantools






Some discussion with BenC, thinking would be to ship all of these patches in the Kernel, Disabled by default and then turn them on at a later date as and when the builds are required. -sladen

XenEnabledKernel (last edited 2008-08-06 16:33:59 by localhost)