Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/xen-feisty
Summary
In edgy we got in a form of Xen that our users can use more easily. This spec for feisty describes improvements to what we have already.
Scope
- We aim to provide "just install it" support for ordinary Ubuntu virtual server domU's on an Ubuntu dom0.
- We will package and integrate existing straightforward management tools for creating, starting, stopping, etc., these domU's.
- Other kinds of domU will not be ruled out by our design if the administrator handles them manually (or if some other tools create them).
Use cases
- 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.
Work items
- Port paravirt-ops to 2.6.19 for testing purposes.
- Enable Xen and paravirt-ops in 2.6.20 (The feisty fawn kernel).
- Synchronize xen-3.0 with xen-unstable.
- Merge Debian's update-grub, which already supports finding xen installs and their kernels; we will have to modify it to cope with our variant on the kernel name mangling.
- Modify everything in xen-3.0 and xen-tools that calls xm create to run some hooks, in particular so that we can:
- Arrange, for all guests that we created and are managing, to copy the kernel/initramfs out, as described below.
- Do some standard networking setup (see below).
- We already have test packages for virt-manager and libvirt.
- Xen 3.0, virt-manager, and libvirt should be included in main.
- xen-tools domU creation should automatically install a suitable kernel image (and modules, and run mkinitramfs) in the new guest; suitable means (for us) the same kernel as the dom0 is running.
- Look into libvirt and virt-manager and see how much support can easily be provided.
- Check whether the checksum offload bug is still present and if so disable the feature (preferably with ethtool -K but with source patch if necessary).
Details
Kernel management
For Ubuntu guests which we create and manage, we want to arrange that the in-guest modules correspond to the provided kernel and initramfs, and we want the kernel update to be driving by the guest.
To this end, we will arrange that each time we boot one of our guests, we mount the guest's filesystem in the host (via a loop device) and copy the kernel out to somewhere in /var on the host, before using that kernel. (If the mount or copy fails we boot the previously-copied-out kernel.)
Open Issues
Since the Xen patches too many files in the kernel source tree, the Xen kernel will be a individual deb as it was in Edgy. Initially the kernel will be based on 2.6.18 until Xen can be ported to 2.6.19. When the port can be made then it will use the feisty fawn kernel as a build dependency. The kernel will be in universe initially to test various options and 2.6.19 Xen enabled kernel will go into main.
It was decided early in the Feisty development cycle that we are going to ship 2.6.20 when feisty is realesed. In 2.6.20, paravirt-ops should be included in this release. Paravirt-ops is an ABI which allows Xen and Vmware to be included in the linux kernel. We will use this interface in order to provide an interface to Xen and Vmware.
Someone needs to look at xen-tools. (action: Chuck)
Notes
Networking: we will set up a bridge automatically on all xen dom0's, even with no guests (this is how xen-3.0 does it already, and is the way upstream does it). This enables both bridged and routed guests. Our guests will be bridged by default and use dhcp to get an ip address.
We considered the use of pygrub, instead of the kernel management approach described above. However, the approach with pygrub and update-grub is more complicated than we need it to be and introduces another dependency on a rather new and ill-documented piece of software. Also, pygrub relies on the bootloader= option in xmdomain.cfg which our xen-3.0 does not support.
Xen provides a way to disconnect and re-attach a block device so that I belive the loop device or LVM can be modified. This also requires more research as well.