When I first heard about Xen, my first idea wasn't that I'd be running it on my laptop. But it works, and it's very convenient. (Your milage may vary--we have seen some laptops that do not work well with the current dom0 kernel we have, and we're still debugging.) While we continue to work on integrating Xen support more closely with rPath's technology, I thought I'd give a step-by-step on what I did.

I should be clear that practically everything here should end up being automated, or at least integrated sensibly into rPath Linux. This explains one way that Xen technology currently in rBuilder Online repositories can be deployed right this minute, while our development work is still underway.

I also want to make it clear that we're confident that there are still bugs here. This is for intrepid explorers -- please report bugs via bugs.rpath.com. You can file them against version @rpl:1.

First, I wanted to convert my existing laptop installation to be a dom0 instance. This required:

1. conary update mkinitrd=rtao.rpath.org@rpl:devel This put a version of mkinitrd on my system that is capable of dealing properly with the xen hypervisor when modifying grub configuration files. (This must precede updating the kernel so that the updated tag handler will work. Because it is re-running depmod for all your kernel images, it will take a while. This is not a bug.)
2. conary update kernel=rtao.rpath.org@rpl:devel[xen] This puts the xen dom0 kernel on my system. Note that there will be two warnings about unknown symbols; this will be fixed later.
3. conary update {glibc,glibc-utils,nscd}=rtao.rpath.org@rpl:devel[xen] This puts a version of glibc on my system that doesn't conflict with Xen
4. conary update bridge-utils=rtao.rpath.org@rpl:devel This adds the bridge-utils package, which Xen requires to set up networking
5. conary update xen=rtao.rpath.org@rpl:1 This adds the xen daemon and management software per se.

After installing those pieces and rebooting into that hypervisor/kernel, my normal running system was also a Xen dom0 instance. Two things to be aware of:

• If you are used to a quiet boot, you are going to be surprised by the amount of output; the Xen hypervisor has a lot to say when it is starting.
• CPU scaling does not work in this dom0 because of the smp kernel in use, which means that I will normally boot the Xen hypervisor/dom0 kernel only when connected to external power. I can boot a standard kernel instead of the hypervisor/dom0 pair using the same userland.

Now I was ready to create a domU instance.

There are a lot of choices here. Generally, you can use a file containing a filesystem or disk image, or you can use a device. That device could be (for example) a partition or LVM logical device. I had an empty partition set aside for testing, so I decided to use that. (Note: I later realized that an image file placed in that partition would have been simpler; take these steps as an example of doing things the hard way.)

I made a fresh ext3 filesystem on that partition and mounted it on /mnt/foo.

1. conary update --root /mnt/foo group-core=:1
2. conary update --root /mnt/foo kernel=rtao.rpath.org@rpl:devel[xen] --no-deps Modules have to match the kernel booted externally; this is the easiest way to do that. (I used --no-deps because I was too lazy to exclude kernel:built-tree and didn't want to pull in the perl dependency.)
3. I created an /mnt/foo/etc/fstab file:

   /dev/sda1   /         ext3    defaults        1 1
   /dev/devpts /dev/pts  devpts  gid=5,mode=620  0 0
   /dev/shm    /dev/shm  tmpfs   defaults        0 0
   /dev/proc   /proc     proc    defaults        0 0
   /dev/sys    /sys      sysfs   defaults        0 0

   (The /dev/sda1 is configuration-specific; see later configuration notes, especially the update on xvd)

4. conary update --root /mnt/foo glibc=rtao.rpath.org@rpl:devel[xen]
5. cp -f /etc/{passwd,shadow,group,gshadow} /mnt/foo/etc/ (You can do something smarter; I happened to know this would be a trivial way to get all the passwords I cared about)
6. I edited /mnt/foo/etc/inittab to comment out starting mingetty on tty2-6 (see below for a better answer)
7. I created /mnt/foo/etc/sysconfig/network-scripts/ifcfg-eth0 with contents

   DEVICE=eth0
   BOOTPROTO=dhcp
   ONBOOT=yes
   TYPE=Ethernet

   (This will get a DHCP address directly from the server my laptop is connected to; the network interface will be bridged.)

8. I created /mnt/foo/etc/sysconfig/network with contents NETWORKING=yes
9. I ran umount /mnt/foo to unmount the partition, since only one instance can have it mounted at once.
10. I ran cp /etc/xen/xmexample1 /etc/xen/xmdevel and then changed some lines in /etc/xen/xmdevel:

    kernel = "/boot/vmlinuz-2.6.16.11-1.smp.xen.x86.i686.cmov"
    ramdisk = "/boot/initrd-2.6.16.11-1.smp.xen.x86.i686.cmov.img"
    memory = 128
    name = "Devel"
    disk = [ 'phy:hda7,sda1,w' ]
    root = "/dev/sda1 ro"
    

    Note that the kernel and ramdisk are the same exact ones that I booted to run the dom0 instance. hda7 is the partition I happened to have free. Note that the sda1 which appears twice has to match what I put in the /mnt/foo/etc/fstab file.

11. xm create -c xmdevel This started my new instance and gave me a console.

You will probably want to change the vif definition to at least provide a consistent hardware address, something like vif = [ 'mac=00:16:3F:00:23:48' ] (change that to something unique...)

Update 1:

While using sda1 as a proxy for a partition was convenient, it's not the best way. It is generally better to use the vxd driver than the proxy. Hard drive images created by rBuilder Online are generally more appropriate for Xen than simple partitions. (To avoid module mismatches and slowdowns from glibc using TLS, put the xen kernel and glibc in the hard drive image.) These images have mount-by-label for the root partition, so you don't have to change that. Use something like

disk = [ 'file:/path/to/myappliance.img,xvda,w' ]
root = "/dev/xvda1 ro"

and the image should Just Work.

Update 2:

Instead of commenting out mingetty lines in inittab, just run these commands:

# mknod tty2 c 4 2
# mknod tty3 c 4 3
# mknod tty4 c 4 4
# mknod tty5 c 4 5
# mknod tty6 c 4 6

This will become unnecessary with a future update of udev.