Bislang habe ich Ubuntu immer mit den Vanilla-Sourcen von Xen eingerichtet, einfach weil der Support für Dom0 (priviligierte Domain) teils fehlte, teils veraltet und instabil war. 12.04 ist die erste LTS-Version, die sich zufriedenstellend “out of the box” als Domain 0 einrichten lässt. Mit verantwortlich ist, dass sich Kernel ab Version 3.0 auf dem Hypervisor Xen starten lassen, gepatchte spezielle Kernel sind heute überflüssig. Die Einrichtung ist recht geradlinig, lediglich einige Kleinigkeiten sind zu beachten.
Weniger geradlinig ist noch immer der Betrieb: Der Einsatz von HVM-Gästen benötigt VME- bzw. SVM-Erweiterungen des Prozessors (in billigen PCs hart per BIOS deaktiviert) und einige Grafikkarten mit KMS bereiten Ärger, genauso wie die proprietären Grafiktreiber von AMD und nVidia. Um schnell ein Demo-Virtualisierungssystem einzurichten, taugt Xen nicht (dafür sind VMware Player oder VirtualBox viel besser geeignet). Wer dagegen extrem flexible Servervirtualisierung mit geringem Overhead und hoher Flexibilität sucht, wird mit Xen jedoch fündig.
Software-Installation
Installiert wird Xen über das Paket xen-hypervisor-4.1-amd64, alle Abhängigkeiten werden dann nachgezogen. kpartx wird für die Einrichtung der domUs benötigt:
sudo apt-get install xen-hypervisor-4.1-amd64 kpartx
Während der Installation fügt Ubuntu einen Bootmenüeintrag “Xen 4.1-amd64″ hinzu, über den Sie in einem Untermenü landen. Das ist ein guter Ansatz, solange mit den Bootoptionen herumzuspielen (vga=normal nomodeset usw.) bis der Server sauber hochfährt und sich stabil benutzen lässt.
GRUB-Konfiguration anpassen
Ich habe mich für eine etwas unorthodoxe GRUB-Konfiguration entschieden. Ein Script /etc/grub.d/98xen sucht den letzten Linux-Kernel und sein Initramfs und fügt für diesen einen Eintrag in der obersten Ebene des GRUB-Menüs ein. Anzupassen sind UUID und Parameter der Module-Zeile. Bitte nach Änderungen das Script einmal im Terminal ausführen, um zu sehen, ob die Ausgabe plausibel ist. Wer bessere Ideen hat, maile mir diese:
#!/bin/sh
LINUXKERNEL=` ls /boot/vmlinuz-3.2* | tail -n1 `
INITRAMFS=` echo $LINUXKERNEL | sed 's/vmlinuz/initrd.img/g' `
XENKERNEL=` ls /boot/xen-4.1* | tail -n1 `
UUID=eb7a7f54-291f-420f-9f26-7d753c857a3d
exec tail -n +15 $0 | sed 's%XENKERNEL%'${XENKERNEL}'%g' | \
sed 's%LINUXKERNEL%'${LINUXKERNEL}'%g' | \
sed 's%INITRAMFS%'${INITRAMFS}'%g' | \
sed 's%ROOTUUID%'${UUID}'%g' | \
sed 's%^#%%g'
# Now the template - starting in line 15 - # will be removed
#menuentry "Xen+PVOPS" {
# insmod ext2
# set root=(hd0,1)
# search --no-floppy --fs-uuid --set=root ROOTUUID
# multiboot XENKERNEL dummy=dummy
# module LINUXKERNEL root=UUID=ROOTUUID ro nomodeset vga=normal
# module INITRAMFS dummy=dummy
#}
Damit das ganze funktioniert muss das Script ausführbar sein:
chmod 0755 /etc/grub.d/98xen
nun noch in der Datei /etc/default/grub den Standard ändern:
# GRUB_DEFAULT=0
GRUB_DEFAULT='Xen+PVOPS'
Nach einem
sudo update-grub
und dem folgenden obligatorischen Reboot sollte das Kommando xm dmesg zeigen, dass unterhalb von Linux Xen 4.1 läuft. Das war die halbe Miete.
Netzwerk für Xen einrichten
Xen benötigt eine Netzwerkbrücke. Die MAC-Adressen der unpriviligierten Domains werden dabei an ein bestimmtes Netzwerkinterface gebunden – in Heimnetzwerken und Büronetzen, in denen Sie die Kontrolle haben, ist das die Standardeinstellung. Alternativ gibt es die Möglichkeit, zu den unpriviligierten Domains zu routen (das behandle ich an dieser Stelle nicht). Passen wir also unsere /etc/network/interfaces an:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_fd 0
Alternativ gerne mit fester IP, Adresse, Gateway und Maske werden vom primären Interface kopiert:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
auto xenbr0
iface xenbr0 inet static
address 10.76.23.55
netmask 255.255.255.0
gateway 10.76.23.252
dns-nameservers 8.8.8.8 10.76.23.252
bridge_ports eth0
bridge_stp off
bridge_fd 0
Danach bitte nochmal Reboot oder wenigstens Neustart des Dienstes Networking.
Meine erste DomU
Meine DomUs (unpriviligierte Domains) liegen unter /usr/local/xendomains. Die zum Testen aufgesetzte unter /usr/localxendomains/12.04ltstest. Sie verwendet den Netinstaller von Ubuntu:
DOMUDIR=/usr/local/xendomains/12.04ltstest
mkdir -p $DOMUDIR
wget -O $DOMUDIR/kernel-install.img http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/vmlinuz
wget -O $DOMUDIR/initrd-install.img http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/initrd.gz
dd if=/dev/zero bs=1M count=1 seek=16383 of=$DOMUDIR/xvda.img
Das Image xvda.img ist ein Sparse File. Es erscheint zwar 16GB groß, nimmt diesen Platz aber zunächst nicht ein. Jetzt noch ne Configdatei $DOMUDIR/xen.cfg:
kernel = "/usr/local/xendomains/12.04ltstest/kernel-install.img"
ramdisk = "/usr/local/xendomains/12.04ltstest/initrd-install.img"
memory = 512
vcpus = 1
name = "ltstest"
vif = [ 'mac=00:16:00:00:42:23' ]
disk = [ 'file:/usr/local/xendomains/12.04ltstest/xvda.img,xvda,w' ]
root = ""
extra = "console=hvc0 ro xencons=tty"
Nun wird die DomU gestartet. Wichtig ist das -c, denn damit wird die Xen-Konsole aufs laufende Terminal geschaltet:
xm create -c $DOMUDIR/xen.cfg
Während der Installation sollte man noch darauf achten, das Paket openssh-server zu installieren, denn die Xen-Konsole ist äußerst unpraktisch (kennt nur 80×25 etc.). Nach der Installation rebootet das System. Dummerweise mit dem Installationskernel. Würgen wir es ab:
xm destroy ltstest
Eine dauerhafte DomU
Es gibt Möglichkeiten, den Kernel und seine Ramdisk vom Festplattenimage zu laden. Diese gefallen mir jedoch nicht, weil sie gute Einfallspunkte für Rootkits sind. Ich kopiere daher Kernel und Initrd. Zunächst erstelle ich ein Loop-Device für das Festplattenimage (die DomU darf nicht mehr laufen!), wofür wir ein freies Loopdevice brauchen (hier wurde /dev/loop0 gefunden):
losetup -f
losetup /dev/loop0 $DOMUDIR/xvda.img
Linux kommt mit Partitionen auf Loopdevices auf Anhieb nicht so toll klar. Hier kommt der Device-Mapper ins Spiel, der Partitionen auf Loop-Devices erkennt:
kpartx -a /dev/loop0
mkdir -p /tmp/xen-domU
mount /dev/mapper/loop0p1 /tmp/xen-domU
Nun kopieren wir den Kernel und das Initramfs:
cp -v /tmp/xen-domU/boot/vmlinuz-3.2.0-24-generic $DOMUDIR/kernel.img
cp -v /tmp/xen-domU/boot/initrd.img-3.2.0-24-generic $DOMUDIR/initrd.img
Zum Abschluss gilt es noch, die Konfiguration der domU anzupassen:
kernel = "/usr/local/xendomains/12.04ltstest/kernel.img"
ramdisk = "/usr/local/xendomains/12.04ltstest/initrd.img"
# ...
# Je nach Partitionierung ist die root-Zeile ggf. anzupassen!
root="/dev/xvda1"
Dann kann das Loopdevice ausgehängt und aufgelöst werden – ich lasse erst alle Devices anzeigen und löse dann von hinten nach vorn:
umount /tmp/xen-domU
ls -lah /dev/mapper/loop0*
dmsetup --remove /dev/mapper/loop0p5
dmsetup --remove /dev/mapper/loop0p2
dmsetup --remove /dev/mapper/loop0p1
losetup -d /dev/loop0
Nun steht dem Start der DomU mit “produktivem” Kernel nichts mehr im Wege. Dieses Mal ohne -c:
xm create $DOMUDIR/xen.cfg
In den nächsten Tagen werde ich mal auf eine Windows Server 2008 DomU eingehen (keine Angst, kostet nix, kann man 240 Tage am Stück gratis nutzen), was ein guter Einsatz für einen Xen-Host ist, der mit Samba Dateidienste für Windows und Linux anbietet und dank Windows Server 2008 auch Terminalserverdienste anbieten kann. Viel Spaß wünscht Mattias Schlenker!
PS: Autoren gesucht! Wer sich zutraut, einigermaßen geordnet zu schreiben, darf sich gerne bei mir melden. Ich betreue derzeit die LINUX INTERN von Data Becker als “Projektleiter” und bin für diese Zeitschrift auf die Suche nach Autoren. Eure Schreibe muss nicht “schön” im schriftstellerischen Sinne sein, aber man muss erkennen, dass Ihr strukturiert denkt. Honorar gibt es natürlich auch.
Also was anderes. Mir kam die Idee das ganze über den ARP Cache zu machen. OMG! Warum das denn?
