Aus dem Rechenzentrum

Am Wochenende hatten wir den Fall das bei einer Xen-Instanz das Dateisystem geprüft und ggf. repariert werden musste. Die Xen-Instanz liegt in diesem Fall in einem Image (gast.img)  welches mit Hilfe des Block-Tap-Mechanismus (blktap) zur Verfügung gestellt wird.

Inhalt des Images gast.img:

 Partition 1     -> /boot
 Physical Volume -> VolumeGroup00 -> LogVol00 (/)  [80 GB]

                                  -> LogVol01 (swap)

Jetzt ist es so, das durch die damals vorgenommene Defaultinstallation das Dateisystem des Wirtes (xenwirt) ebenso aufgebaut ist wie das des Gastsystems:

 Partition 1     -> /boot
 Physical Volume -> VolumeGroup00 -> LogVol00 (/)   [320 GB]
                                  -> LogVol01 (swap)

Ok, zurück zum Thema. Wir wollen das Dateisystem des Gastes checken (fsck) und anschließend einbinden (mounten). Nachfolgend alle notwendigen Schritte:

Mit Hilfe von kpartx alle Partitionen des Images erkennen und die dazugehörige device-map (/dev/mapper/loop<Loopbackdevice>p<Partitions>) erstellen

kpartx -a /xen/gast.img

Angenommen kpartx verwendet jetzt das Loopbackdevice /dev/loop7, dann findet man jetzt die Partitionen des Images unter /dev/mapper/loop7p*. Die erste Partition (/boot) kann man jetzt schon direkt ansprechen und z.B. einbinden (mount /dev/mapper/loop7p1 /mnt/tmp). Durch das Ausführen von vgscan werden jetzt die neu hinzugekommenen VolumeGroups gefunden und diese könnten jetzt sogar eingebunden und verwendet werden. Hier stoßen wir jetzt leider nur auf unser kleines o.a. Problem: Beide VolumeGroups haben den gleichen Namen, nämlich VolGroup00. Damit wir nun die „richtigen“ LogicalVolumes ansprechen können müssen wir die neu hinzugekommene VolumeGroup umbenennen.  Dazu kopieren wir uns die UUID der VG (die mit der Größe von 80GB) die uns das Kommando vgs liefert und nutzen die ID als Identifikationsmerkmal.

vgscan

vgs -v

Als neuen Namen verwenden wir nun etwas Eindeutiges.

vgrename H3sOYJ-ywTE-vNTf-pm0i-De3zXU VolGroupGuest01

Jetzt können wir die umbenannte VolumeGroup aktivieren damit uns (endlich) unter /dev/VolGroupGuest01/ die Logical Volumes bereitstehen. Einer Überprüfung der  root-Partition des Gastes steht nun nichts mehr im Weg.

vgchange -ay VolGroupGuest01

fsck.ext3 -C -f /dev/VolGroupGuest01/LogVol00

Da wir den Namen der VolumeGroup nach dem fsck jetzt nicht wieder in VolGroup00 umbenennen können (da es diese VG ja schon gibt!), ist es Notwendig das Gastsystem anzupassen. Wir binden das Gastsystem unter /mnt/guest1 ein und ändern die Grubkonfiguration /boot/grub/grub.conf, die /etc/fstab und die initrd folgendermaßen ab:

Einbinden des Gastsystems:

mount /dev/VolGroupGuest01/LogVol00 /mnt/guest1

mount /dev/mapper/loop7p1 /mnt/guest1/boot

Anpassen /etc/fstab

perl -pi -e „s/VolGroup00/VolGroupGuest01/“ /mnt/guest1/etc/fstab

Anpassen /boot/grub/grub.conf

perl -pi -e „s/VolGroup00/VolGroupGuest01/“ /mnt/guest1/boot/grub/grub.conf

Anpassen /boot/initrd-*

mkdir ~/tmp
cd ~/tmp
cp /mnt/guest1/boot/initrd-<KERNELVERSION>.img ./initrd.gz
gunzip initrd.gz
mkdir content
cd content
cpio -id < ../initrd

perl -pi -e "s/VolGroup00/VolGroupGuest01/" ./init

cd ~/tmp/content
find . | cpio --create --format='newc' > ~/tmp/newinitrd
cd ~/tmp
gzip newinitrd
mv newinitrd.gz /mnt/guest1/boot/initrd-<KERNELVERSION>.img

Jetzt können wir das Dateisystem wieder aushängen, die VolumeGroup deaktivieren, das Devicemapping entfernen und das Loop-Device aushängen.

umount /mnt/guest1/boot

umount /mnt/guest1

vgchange -an VolGroupGuest01

kpartx -d /dev/loop7

Das Image steht jetzt wieder wie gewohnt für xen zur Verfügung. In unserem Fall ist der Gast ohne weitere Probleme gebootet.

Ein ärgerlicher Vorfall erwischte uns, unpassenderweise auch noch mitten am Tag. Für einen Kunden betreiben wir ein Xen-Host, auf dem insgesamt drei praktisch identische virtuelle Maschinen laufen. Aus einem nicht weiter relevanten Grund rebootete der Kunde eine der drei virtuellen Maschinen – an sich ein normaler Vorgang.

Nicht normal war hingegen, dass die Maschine nicht mehr hochfuhr, und zwar mit einem Effekt, der uns völlig neu war: Der Kernel bootete ein bisschen und fror dann ein. Meistens, aber nicht immer an der gleichen Stelle. Google war absolut nicht hilfsbereit, denn egal an welcher Zeile die Instanz einfror, die Suchmaschine lieferte sie nur im Zusammenhang mit weiteren Bootmeldungen, und alles, was sich zu Suchbegriff-Kombinationen aus „xen“, „linux“, „kernel“, „freeze“ etc. bilden ließ, lieferte entweder zuviel oder wenig Ergebnisse.

Nun blieben nicht viele Möglichkeiten: Allgemein würde ich wohl vermuten, dass, wenn ein Kernel beim Booten einfriert, und dies an wechselnden Stellen, ein Hardware-Problem nicht übermäßig unwahrscheinlich wäre. Alternativ ist vielleicht „ein Bit auf der Platte gekippt“, wie Christopher einwarf. Um letzteres auszuschließen, haben wir verschiedene Kernel gebootet. Normalerweise bootet das Gastsystems mittels pygrub einen eigenen Kernel; es kann aber auch mit einem Kernel des Gastsystems booten. Keine der beiden Varianten funktionierte, was uns leicht nervös machte. Es gab seit dem letzten Reboot des physischen Servers keinerlei Updates des Xen-Kernels oder der Xen-Userspace-Tools. Die Instanz hatte so, wie sie vorlag, bereits erfolgreich gebootet. Wieso nun nicht mehr?

Auf dem Server befand sich zudem noch das „Master-Image“, von dem aus die anderen drei Instanzen erzeugt worden waren. Testweise erzeugten wir noch eine weitere Test-Instanz basierend auf dem Master-Image – und auch die bootete nicht.

Es musste also die Hardware sein, da waren wir sicher. Einen Reboot des Wirts durchzuführen scheuten wir uns, da ja noch zwei weitere Instanzen darauf liefen – und zwar völlig störungsfrei. Ein Reboot der physischen Hardware könnte die Erreichbarkeit dieser noch laufenden Instanzen ebenfalls beeinträchtigen – und das wollten wir nicht riskieren. Unser Plan sah daher vor, das Image der (gestoppten) Instanz auf andere Hardware mit einem Xen-Wirt zu kopieren und die virtuelle Maschine dort zu booten. Kapazitäten waren ausreichend vorhanden. Der Kopiervorgang strapazierte unsere Nerven und auch die unseres Kunden, aber es half letztlich ja nichts. Wenn überdurchschnittlich hohe Verfügbarkeit ein Muss ist, bauen wir gerne einen Failover-Cluster dafür auf; für den konkreten Anwendungsfall war das aber nicht gefordert.

Nachdem dann endlich das Image übertragen war, folgte Ernüchterung: Auch dort bootete die Instanz nicht – mit exakt den gleichen Symptomen. Nun machte sich wirklich Ratlosigkeit breit. Wenn nun wirklich nichts, aber auch gar nichts an den Gegebenheiten verändert wurde, weder auf dem Gast noch auf dem Wirt, wieso bootete dann die Instanz nicht einmal mehr auf anderer Hardware..? Noch verzweifelter wurden wir, als sich selbst völlig frische, mittels virt-install angelegte Images nicht booten ließen – virt-install zog sich vmlinuz und initrd.img aus dem Netz, bootete – und fror ein.

Da auf dem separaten Xen-Server ansonsten nur noch eine einzige Instanz lief, deren Verfügbarkeit nicht mit hoher Priorität gegeben war, haben wir daher beschlossen, die fragliche Hardware einmal zu rebooten, und wir verstehen es bisher noch nicht, aber: Nach dem Reboot lief alles wieder 1a. Das rüberkopierte Image bootete, es ließen sich mit virt-install neue Instanzen anlegen – alles wunderbar.

Dadurch ermutigt rebooteten wir auch den ursprünglichen Wirt. Das Risiko, zwei weitere Xen-Instanzen während dieser Zeit temporär unerreichbar zu machen, war angesichts der neuen Entdeckung geringer einzuschätzen als vorher. Und, welch Wunder: Nach einem Reboot fuhren alle drei Instanzen anstandslos hoch.

Eine vollständige Klärung haben wir bisher nicht erfahren dürfen. Wir wissen nun, dass es offensichtlich Situationen gibt, in denen sich der Xen-Hypervisor so verfährt, dass er Gäste nicht mehr hochfahren kann, und zwar ohne aussagekräftige Fehlermeldungen. Auf dem Wirt war weder per dmesg noch in irgendeinem Logfile irgendetwas zu erfahren, was ihm nicht passen würde. Das ist so natürlich äußerst unbefriedigend, denn ein Reboot ist so gesehen natürlich eigentlich nur die letzte Maßnahme. Zugegebenermaßen ist eine derartige Situation aber nun auch zum allerersten Mal eingetreten, und wir betreiben durchaus viele Xen-Instanzen, und das auch durchaus schon seit längerer Zeit. Zurück bleibt der unbefriedigende Geschmack, ein Problem gelöst, aber nicht begriffen zu haben. Wir werden das im Auge behalten – vielleicht haben wir Glück und eine unserer Testmaschinen verfällt ebenfalls in diesen Zustand, so dass wir die Situation ohne den Druck, eine Maschine wieder erreichbar machen zu müssen, analysieren können. Nachträge hierzu veröffentlichen wir natürlich gerne.