Im Gegensatz zu den Karlsruher Mitbewerbern bietet Hetzner bei seinen dedizierten Servern keine serielle Konsole mit an. Zwar benötigt man dieses Feature nicht wirklich oft, praktisch ist es aber dennoch, wenn man ein Unwohlbefinden des Servers beim Bootvorgang genauer untersuchen möchte bzw. auch einfach nach einem Systemupgrade den Bootvorgang miterleben will.

Als Ersatz gibt es bei Hetzner schon längere auf Anfrage stundenweise die sogenannte LARA, die ich bisher zum Glück nicht gebraucht habe. Die LARA wird an die Keyboard-, Video- und Mouse-Anschlüsse angeschlossen und bietet dem Kunden dann über ein Java-Applet Zugriff auf seinen Server. Damit hat man sogar etwas mehr Möglichkeiten als mit einer seriellen Konsole, da man mit der LARA auch den Bootvorgang boch vor dem Bootloader beobachten kann. Im Notfall muss man aber erst eine Supportanfrage absetzen und drauf hoffen, dass zeitnah eine LARA verfügbar ist.

Als Zwischenlösung gibt es seit etwas über einem Jahr auch VKVM bei Hetzner. Dabei wird der Server über das Netzwerk in ein Rescue-System geboot und darin eine VM gestartet, auf die man per VNC zugreifen kann. Diese VM kann dann das System von der Platte des Servers starten, so dass man den kompletten Bootvorgang miterleben kann.

Nachdem ich nun auch einen noch nicht produktiven Server zur Hand hatte, um das mal auszuprobieren, habe ich die Gelegenheit genutzt. Besser man macht sich vorab mit dem Feature vertraut anstatt erst im Notfall wenn man dann eh schon aufgeregt ist und die Zeit knapp ist.

Als erstes wählt man im Hetzner Robot bei seinem Server unter Rescue VKVM in der zur Installation passenden Variante aus. Man erfährt sofort URL und Zugangsdaten der VKVM-Konsole. Nicht wundern braucht man sich darüber, dass die URL auf die Haupt-IP-Adresse des eigenen Servers verweist. Nun löst man den Restart des Servers aus; entweder per Reboot auf dem Server selbst oder – wenn dieser nicht mehr erreichbar ist – über den Hetzner Robot. Es dauert nun einige Zeit bis das Rescue-Virtualisierungs-System hochgefahren ist. Nach einiger Zeit kann man dann per Java-fähigemBrowser auf die genannte URL zugreifen und sich mit den genannten Zugangsdaten anmelden. Es startet ein Java-Applet über dass man Zugriff auf die Konsole des virtualisierten Systems erhält. In dieser Konsole sieht man nun eine etwas verwirrende Boot-Schleife, bei der scheinbar versucht wird, das lokale System zu starten, was jedoch nicht klappen mag. Des rätsels Lösung ist, auf folgende Frage mit Q zu antworten:

Boot from (N)etwork or (Q)uit?

Erst dadurch wird der Bootloader auf der Festplatte des eigenen Systems gestartet, der Default N bietet hingegen weitere Diagnose- und Rescue-Möglichkeiten an aber nichtden Zugriff auf das installierte System. Einen weiteren Fallstrick gibt es nun beim Start des installierten Systems: Benutzt man einen Kernel, der auf Hardware-Virtualisierungstechniken angewiesen ist, z.B. mit Xen-Support, so scheitert der Start, denn man ist ja bereits in einer virtuellen Umgebung in der keine Hardware-Virtualisierungstechniken mehr verfügbar sein können.

Hat man auch diese Hürde geschafft startet endlich das installierte System und ist dann auch aus dem Internet z.B. per SSH erreichbar, was für Arbeiten an den Konfigurationsdateien sicherlich etwas angenehmer ist als der Zugriff über die Konsole im Java-Applet.

Verzwickt ist zum Schluss nochmal der Wechsel zurück zum „echten“ System. Die Menüpunkte des Java-Applets, die einen Strg+Alt+Entf senden lassen bzw. einen Hardware-Reset durchführen lassen wirken sich nur auf die virtuelle Umgebung aus, d.h. man verläßt damit das Rescue-VKVM-System nicht. Erst durch einen richtigen Reboot aus dem Hetzner-Robot kommt man hier wieder raus.

Fazit: Von der Handhabung her etwas komplizierter als eine serielle Konsole her, von den Diagnose- und Reparaturmöglichkeiten möglicherweise sogar etwas besser.