Es kam wie es kommen musste: Kurz vor Ende des Urlaubs schmierte der Büroserver ab — ein alter Athlon XP 2000+ von ca. 2004, der in erster Linie als Datengrab dient, aber auch einige Xen-Domains für Testzwecke und den Festplattenvideorecorder beherbergt. Ein normales PC-System, das unter Ubuntu plus Xen lief, einzige Besonderheit eine Menge Xen-Domains für verschiedene Zwecke und ein paar durchgeschleifte PCI-Karten. An sich nichts Wildes, schließlich sind alle geschäftskritischen Daten mehrfach gesichert. Es sah also nach einer einfachen Sache aus: Hardware kaufen, auf der halblebigen alten Maschine einen frischen Kernel bauen, Mainboard (Sockel 775), Prozessor (billiger Zweikern-Pentium) und RAM tauschen, Reboot und gut.

Denkste…

Auf dem Büroserver lief ein Vanilla-Xen mit selbstgebautem Kernel. So sollte es auch bleiben. Für ein Update des Ubuntu 7.10 mit Xen 3.2 bestand zunächst keine Veranlassung, ich besorgte mir also frische openSUSE-11.0-Kernel-Quellen — die sind relativ aktuell (2.6.25) und enthalten die Xen-Patches mit all den von mir benötigten Features. Dummerweise brach der Build mit einem Compile-Fehler ab — möchte openSUSEs Kernel etwa einen bestimmten Compiler? Da die Dom0 letztlich nicht besonders viele Dienste beherrbergt und eigentlich dazu dient, Geräte an die DomUs durchzuschleifen, entschied ich mich für das Aufsetzen einer frischen Dom0. Als Distribution sollte openSUSE 11.0 zum Einsatz kommen, schließlich ist Novell neben RedHat der Distributor mit dem stärksten Xen-Engagement und sollte daher eine komplette und gut abgestimmte Dom0 liefern. Leser, die über planet.ubuntuusers.de auf diesen Eintrag kamen, mögen mir verzeihen.

Und dann nach Netzwerkprobleme

Als Installationsmedium verwenden wir gerne einen PXE-/TFTP-Bootserver. Da genügt es, den Rechner ans Netz zu stöpseln, das BIOS korrekt einzustellen und dann ein paar Sekunden auf das Bootmenü zu warten. Der neue Rechner lud auch brav Kernel und Initrd, fand aber danach keinen Link mehr. Gnarrrr…

eth0: RTL8168c/8111c at 0xee112000, 00:21:de:ad:be:ef, XID 3c4000c0 IRQ 18

Das Problem ist besonders bei Realtek-Karten bekannt und tritt immer wieder einmal auf: Anscheinend bleiben Reste des PXE-Codes im Speicher der Karte, worauf diese vom Kernel nicht richtig initialisiert werden kann. Ähnliche Probleme treten manchmal beim Hin- und Herbooten zwischen verschiedenen Betriebssystemen auf. Meist hilft ein BIOS-Update in Kombination mit den aktuellsten Treibern (sprich: einem frischen Kernel oder Herstellertreiber). Das war mir dann zu aufwendig, ich deaktivierte den PXE-Boot und entschied mich für die Installation per USB-DVD-ROM.

Juchhu, er bootet

Die Installation der nackten openSUSE und die Nachinstallation von Xen sowie das erste Update mittels zypper lief problemlos durch — ich hätte ehrlich gesagt bei einem Minimalsystem nichts anderes erwartet. Xen wurde sauber in der Grub-Konfiguration eingetragen und ich selbst fügte dem Linux-Kernel noch die Einträge zum Durchschleifen von USB- und DVB-Karte hinzu:

pciback.permissive pciback.hide=(0000:06:00.0)(0000:06:00.1)(0000:06:00.2)(0000:06:01.0)

Zu früh gefreut

Dummerweise lies sich die DomU mit dem Videorecorder nicht starten. Das ist die einzige Domain, die im Dauereinsatz auf durchgeschleifte PCI-Karten zugreift. Der Aufruf von dmesg schuf Klarheit: Die beiden pciback.-Bootparameter waren unbekannt. Ein Blick in openSUSEs Kernelkonfiguration zeigte die Ursache: Der PCI-Backend-Treiber war als Modul kompiliert, was zur Folge hat, dass erst der Kernel lädt und PCI-Karten initialisiert und dann der Backend-Treiber diese nicht mehr maskieren kann. Ich installierte also die Kernelquellen, passte die Optionen für den Backend-Treiber an (“Backend driver support” und “PCI-device backend driver” fest einkompiliert statt Modul und “PCI Backend Mode (Passthrough)”), versah den Kernel mit einem eigenen Prefix und kompilierte ihn neu.

Nach mkinitrd, Anpassung der Grub-Konfiguration und Reboot war auch diese Hürde gemeistert. Es war Mitternacht, ein guter Zwischenstand, Zeit ins Bett zu gehen.

Das lässt mich kalt (der nächste Morgen)

Und wieder einmal sprang eine Festplatte nach dem Auskühlen nicht an. Wahrscheinlich ist das Öl in einem Lager etwas verharzt. Da die betreffende Festplatte Teil eines RAID5-Verbundes ist, verzichtete ich auf den Trick mit dem Fön und kaufte einfach eine neue. Sollte jemand auf dasselbe Problem stoßen: Zunächst startet man das Array ohne die defekte Festplatte (mit --run oder --force)…

root@kiste# mdadm --assemble --run /dev/md0 /dev/sdd1 /dev/sde1 /dev/sdf1
mdadm: /dev/md0 has been started with 3 drives (out of 4).

Dann partitioniert man die neue Platte und fügt die neue Partition dem Array hinzu:

root@kiste# mdadm --add /dev/md0 /dev/sdc1
mdadm: added /dev/sdc1

Ein Blick ins /proc zeigt dann den Synchronisiationsfortschritt:

root@kiste# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdc1[4] sdd1[1] sdf1[3] sde1[2]
      1465151808 blocks level 5, 64k chunk, algorithm 2 [4/3] [_UUU]
      [>....................]  recovery =  0.2% (1398528/488383936) finish=251.2min speed=32304K/sec
      
unused devices: 

Das RAID-Array kann jetzt bereits verwendet werden, allerdings ist die Performance unterirdisch. Zumindest auf das Kopieren oder Synchronisieren großer Datenmengen sollte man also noch verzichten.

Lästige Kleinigkeiten

Soweit, so gut. Einige Kleinigkeiten bleiben. So verwendet meine Videorecorder-DomU noch einem älteren openSUSE-Xen-Kernel, dessen USB-Massenspeicher-Treiber reproduzierbar abstürzt, wenn eine Festplatte oder ein DVD-ROM angeschlossen ist. Stöpsele ich nach dem Boot an, funktioniert alles einwandfrei. Hier werde ich wohl um einen frischen Kernel nicht herumkommen. Bis dahin lebe ich mit dem etwas aufwendigeren Reboot.

Warum tut man sich soetwas überhaupt an? Ich nutze Xen, weil es sich um die flexibelste Virtualisierungslösung handelt, insbesondere wenn PCI-Karten an unpriviligierte Domains durchgereicht werden sollen. Dazu kommt der geringe Overhead durch Xen selbst. Allerdings haben sich seitens Citrix in letzter Zeit einige Schludrigkeiten eingeschlichen. So ist der originale Linux-Kernel mit Xen-Patches noch auf Stand von 2.6.18, die Xen-Unterstützung im Linux-Kernel reicht gerade für den Betrieb einfacher DomUs und gerade kleinere Distributionen tun sich schwer mit der zeitnahen Integration von Xen-Patches in aktuelle Kernel. Auch Novells Nachlässigkeit bei der Konfiguration des PCI-Backends zeigt, dass man dort Xen wohl nicht mehr ganz so hoch priorisiert wie noch vor gut einem Jahr. Klar, dass Citrix zusammen mit den großen Distributoren die kommerziellen Xen-Varianten verkaufen möchte, aber nur eine breite Nutzerbasis in der Community kann auch dafür sorgen, dass ein Produkt ausgereift und gut getestet am Markt bestehen kann. Eine Mindestvoraussetzung dafür sollte sein, dass aktuelle Kernel bereitstehen und sich als stabil deklarierte Releases auf aktuellen Distributionen kompilieren lassen.