Dapper on XEN (part 1/1, unfinished)

I need to do some work on a Dapper system, so it's time to try out xen:

apt-get install linux-image-2.6-xen-686 xen-hypervisor-3.0-i386 xen-utils-3.0 xen-tools

xen-tools tries to recommend xen, which is old and has been requested to be removed from the archive. The recommends needs to be ignored, which is not that trivial to do with aptitude.

The linux-image doesn't happen to have an initrd. The bug has already been reported. One can recreate one using::

mkinitrd -o/boot/initrd-2.6.16-2-xen-686.img  2.6.16-2-xen-686

Then one adds this to /boot/grub/menu.lst:

title Xen
root (hd0,0)
kernel /boot/xen-3.0-i386.gz
module /boot/vmlinuz-2.6.16-2-xen-686 root=/dev/hda1
module /boot/initrd.img-2.6.16-2-xen-smp

And it boots lovely:

# xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      939     2 r-----  4677.9

Now xen-tools provides xen-create-image. I'll try to create the Dapper image (deboostrap in my system has already been changed to be able to install dapper):

xen-create-image --size=4G --swap=128M --dhcp --volume=marvin \
                 --hostname=cavazza --dist=dapper --fs=xfs

But I get:

[...]
Creating swapfile : /dev/marvin/cavazza-swap
Done

Creating disk image: /dev/marvin/cavazza-root
Done

Creating xfs filesystem
Done


Installing the base system.   This will take a while!

Copying files from host to image.
Finished
Something went wrong with the debootstrap installation
Aborting

I love detailed error messages. This one is not.

So I'll have to do by hand. The documentation says:

Before you can start an additional domain, you must create a configuration file. We provide two example files which you can use as a starting point:

But in Debian there's no trace of the two example files. I've reported to Guido Trotter. Then I googled for the two files and found them.

Now, on to adapt Dapper to run under Xen. The good Ubuntu wiki has an HOWTO which crudely makes you install the Tarballed Pre-built installations of Xen 3.0. It's sad that xen-enabled kernels didn't make it into Dapper proper.

I can make this:

kernel = "/boot/vmlinuz-xen-domu"
memory = 128
name = "Dapper"
disk = [ 'phy:marvin/dapper,hda1,w' ]
dhcp="dhcp"
root = "/dev/hda1 ro"

I used the pre-built kernel as a domU, but:

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1)

Sigh. I'll try with the Debian Xen-enabled kernels. Installing yaird and linux-image-2.6.16-2-xen-686_2.6.16-14_i386.deb and linux-modules-2.6.16-2-xen-686. It WORKS!

Now, that's not Dapper: that's a debootstrap install of it. No user, no root password, no desktop, no shiny Ubuntu custom config. How to finish the installation? No idea. In the past, I could run base-config, but now it doesn't exist anymore.

It seems that the best bet is not to use debootstrap, but to install the CD in the LVM partition using QEMU and then chroot into it and then install the debian xen kernel to boot it.

A QEMU install will take ages, and I expect some trouble, like getting partman to see LVM. Maybe I better install on a disk image file and then use tar and netcat to bring the ubuntu installation out of the disk image and into the LVM image.

For today, I didn't make it. This job slips another day. Frustration. I hope that at least this description of my efforts so far can be helpful to someone trying similar things.

One suggestion I got was to boot the Dapper CD and install from there. I can't: this computer has no bootable CD.

Update: I found out http://xensource.com/summerofcode.html and it says:

Project Idea 3: Xen Desktop Outside of Domain 0

This project would deliver a Xen desktop to the user of a client system that presents an abstraction of a virtual desktop to the user in which multiple guests share the virtual desktop, each with a subset of the desktop resources (pixels, etc). Smart management of the sound drivers would allow mixing of sound from multiple guests to the single device used for output.

Microphone input could be broadcast to all guests. Technologies such as ALSA already emulate playback settings by downsampling for the hardware etc. so its not hard to imagine a xen-snd-front device munging the data to a common format used for the internal sound card. Issues: synchronization of playback.

So, what I'm trying to do has been proposed as a SoC project and (I guess) is something that can't be done overnight. Although I was planning to run a displayless gdm accessed with XDMCMP from domain0's X server, and to just hand out the audio card to the domU using pciback, so my task would have been easier.

Thus I give up using Xen for this one.

I'll work around the lack-of-bootable-cd limitation of this computer by installing Ubuntu using QEMU. Which I found out requires using the "Alternate install" CD. The desktop install CD is a live CD installing with Ubuntu Expresso, and the live CD doesn't seem to work in QEMU.

Or, I'll install in a LVM partition in the laptop and then move it around using the network. This one's probably faster.

Could this experience be an interesting use case for Edgy Eft?