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.