Xen “ready to go” images for x86_64

You can find “ready to go” images for Xen 3.0 here. I created both a Debian testing and a Fedora Core 4 image.

Note that these images are x86_64 (or amd64) only!

Edge resistance in metacity and I/O scheduler

Edge resistance

Because else people are most likely going to kill poor Elijah, I created a patch that makes the new edge resistance feature of metacity optional.

Paolo asked me to do it in such a way that you can specify how much pixels to resist, rather than completely disable it. Feel free to improve folks! :p

Kernel I/O scheduler

Oh and because somebody was complaining about the kernel elevator, I started questioning how I switch the I/O scheduler for a specific block device. So I ended up reading block/scheduler.c and block/rr_rw_blk.c and found that you can set it using

echo "[scheduler]" > /sys/block/[device]/queue/scheduler

Cat the same file to get a list of available schedulers. Well, all I can say is that it’s not very well documented.

Putting Xen 3.0 in production

Remember I talked about Xen last week? Well I just started migrating my web-data to a new such Xen guest operating system. If you have difficulties watching my web site(s), please do inform me about it.

later this week is the Postfix (smtp) and the courier (imap) going to be migrated. So people who’ll be sending e-mails might (however, shouldn’t) get difficulties since it involves changing the IP address of the MX of my domains. Note that if it appears on p.g.o, p.g.o’s nameserver in in sync and the stuff worked. So I’ m using p.g.o. for testing. Hah!

So .. let’s now hope this Xen on x86_64 is more stable than the release sais it is!

Today I stepped in the shoes of a Linux administrator

I decided to install Xen 3.0 on the SuperMicro SuperServer 6014H-T with RAID 1 using Fedora Core 4 as operating system.

Sooner or later will this device be used as host for one of my many
virtual machines of which one will run this little blog.

This device contains a ICH5 and a Marvell 88SX6541-BCZ SATA controller,
two Intel Xeon(TM) CPU 3.00GHz x86_64 and some other bla bla hardware.

I partly succeeded. I haven’t yet got the Marvell SATA controller working since that one isn’t yet supported in the kernel being
used by the Xen 3.0 version (it’s using 2.6.12). This was my procedure:

Buy yourself two SATA cables of 50 cm. The current ones are way to short to reach the ICH5 controller.

Open the device and connect your harddisks to the ICH5 controller. The
SATA ports are right behind the standard PATA controllers (behind the
blue and the black IDE controllers). Look in your manual page 5-9.

Insert the Fedora Core 4 x86_64 cdrom 1 and install using the following
partitioning settings (don’t install much, it’s just your dom0):

/dev/sda1: /boot (100M)
/dev/sdb1: /boot_backup (100M)
/dev/sda2: Software RAID (2000M
/dev/sdb2: Software RAID (2000M)
/dev/sdaX, /dev/sdbX: other partitions
/dev/sdaY, /dev/sdbY: swap
Software RAID: / (using sda2, sdb2)

[root@oceanus ~]# yum update && reboot

You’ll now have the sata_mv module as it’s in the 2.6.14
kernel which is available as a Fecora Core 4 update. If you load it you can
see the Marvell 88SX6541-BCZ SATA controller being empty in dmesg.

Regretfully is the Xen 3.0 version using Linux kernel 2.6.12 which
doesn’t yet support the sata_mv driver. So we’re going to leave our
hotswap controller for what it is and hope that the next Xen release
will use Linux kernel 2.6.14 or newer.

Download Xen-3.0 (the tarball release).
The Xen 3.0 Fedora Core 4 binary release install will totally corrupt your x86_64 packages. If you forcefully attempt to install
them, after force installing the e2fsutils you’re mount and umount tools will no longer function. If you
did, you can recover using a Fedora Core 4 rescue disk.

Untar and install it using the defaults. Don’t yet do the grub update. Or do it but watch out! You do need to add an initrd and
you should remove the boot from the /boot/blabla from each line. That’s because we’ve installed /boot to sda1 as
a partition with only /boot on it.

[root@oceanus ~]# cd /root
[root@oceanus ~]# mkinitrd -v -f --with=ipv6 --with=e1000  --with=ext3 \
	--with=jbd --with=raid1 --with=sd_mod --with=scsi_mod \
	--builtin=ata_piix --builtin=sata_mv --builtin=dm_mod \
	initrd-2.6.12.6-xen.img 2.6.12.6-xen
[root@oceanus ~]# cp initrd-2.6.12.6-xen.img /boot
[root@oceanus ~]# echo >> /etc/grub.conf
[root@oceanus ~]# echo "title Xen 3.0 / XenLinux 2.6" >> /etc/grub.conf
[root@oceanus ~]# echo -en "\tkernel /xen-3.0.gz console=vga" >> /etc/grub.conf
[root@oceanus ~]# echo -en "\tmodule /vmlinuz-2.6-xen root=/dev/md0 ro console=tty0" >> /etc/grub.conf
[root@oceanus ~]# echo -en "\tmodule /initrd-2.6.12.6-xen.img" >> /etc/grub.conf
[root@oceanus ~]# reboot

[root@oceanus ~]# uname -a
Linux oceanus 2.6.12.6-xen #1 SMP Sun Dec 4 20:40:43 GMT 2005 x86_64 x86_64 x86_64 GNU/Linux
[root@oceanus ~]#

[root@oceanus ~]# mount
/dev/md0 on / type ext3 (rw)
...
[root@oceanus ~]#
[root@oceanus ~]# cat /proc/cpuinfo | grep processor
processor       : 0
processor       : 1
processor       : 2
processor       : 3
[root@oceanus ~]#

GParts and a shared mainloop. Will it happen?!

This is soooooooo damn cool. More information here, here, here, of course here and here, and finally here.

I’m most likely going to use my upcoming holiday to help the project. I hope other developers of the different free desktop environment communities will follow.