Mit vmkfstools und vCenter Converter: So retten Sie defekte virtuelle Maschinen
Wie lassen sich defekte virtuelle Maschinen noch retten? vmkfstools und vCenter Converter bieten mögliche Lösungswege.
Vor kurzem fiel mir ein interessantes Projekt in den Schoß: Man übergab mir eine defekte virtuelle Maschine (VM) auf einem USB-Stick, ohne jedes funktionierende Backup. Wie lässt sich also eine defekte VM retten? Derlei ist sicherlich nicht direkt die übliche Aufgabe eines VMware-Administrator, doch wie ich diese Aufgabe meistern konnte, dürfte interessant für jeden sein, der vor einer ähnlichen Aufgabe steht.
Ein wenig zum Hintergrund: Ein Windows-Administrator hatte eine virtuelle Maschine auf ein USB-Laufwerk kopiert. Es lag in der Projektnatur begründet, dass ich diesen Administrator nicht zwecks weiterer Hilfestellung kontaktieren konnte. Ich musste zurechtkommen mit dem, was ich hatte. Als ich das Laufwerk öffnete, fiel mir fast das Herz in die Hose: Darauf war nur eine einzige VMX-Datei und die Dateien zu finden, die die virtuellen Laufwerke enthielten.
Installationsversuch der defekten VM von vSphere aus
Mein erster Plan war es, die Dateien einfach so zu importieren, wie sie vorhanden waren. Ich hoffte darauf, dass die fehlenden Dateien bei Bedarf einfach ergänzt würden. Ich erzeugte also einen Ordner in einem freien Datastore und lud die Dateien darauf hoch. Ich versuchte die VM per Rechtsklick auf „Dem Inventar hinzufügen“ zu importieren, doch der vSphere-Client verweigerte sich und hinterließ etwas, das sich als verwaiste VM herausstellen sollte.
In diesem Moment überlegte ich, ob es nicht einfacher sein könnte, die Laufwerke in eine neue virtuelle Maschine einzuhängen. Allerdings wusste ich noch nicht einmal, welches Betriebssystem die VM ursprünglich hatte. Glücklicherweise ergab ein kurzer Blick in die VM-Datei, dass es sich um Windows Server 2003 handelte.
Nachdem ich das Betriebssystem identifiziert hatte, erzeugte ich eine leere Shell, einschließlich korrekter virtueller SCSI-Hardware, die nun alle benötigten Dateien enthielt, wie die NVRAM- und die VMX-Datei. Nachdem ich das jetzt vorhandene Laufwerk durch das mir übergeben ersetzt hatte, war ich optimistisch und fuhr die virtuelle Maschine hoch.
Es wird immer schlimmer: Die defekte VM startet nicht
Statt einer VM bekam ich aber nur eine merkwürdige Fehlermeldung über den Typ des virtuellen Laufwerks der Maschine zu sehen. Sie wollte einfach nicht hochfahren. Einige Google-Suchen später wusste ich bereits mehr über den Ursprung dieser Maschine und hatte herausgefunden, dass sie von einem VMware Server betrieben worden sein musste.
Wenn ich hier VMware Server sage, dann meine ich damit wohlbemerkt nicht den ESXi-Hypervisor, sondern das Legacy-Produkt aus dem Jahr 2006, das 2010 eingestellt wurde. VMware hatte das Produkt damals als kostenlose Alternative zum vollständigen ESX-Paket angeboten. Grundsätzlich handelt es sich dabei um einen Typ 2-Hypervisor, der auf einem Windows-basierenden Server ablief – mit dem ich mich aber schon seit längerem nicht mehr auseinandergesetzt habe.
Auch vmkfstools knackt die defekte VM nicht
Woher nun wusste ich überhaupt, dass diese Dateien einem VMware Server entsprungen waren? Es lief auf die Schlussfolgerung hinaus, dass die Maschine deswegen nicht hochfahren wollte, weil die VMDKs das falsche Format hatten. Um sie in ein ESXi-verträgliches Format umzuwandeln, musste ich die vmkfstools verwenden. Nachdem ich mit der Konvertierung fertig war, hatte die Dateigröße beträchtlich zugenommen. Erneut war ich voll der Hoffnung.
Kaum hatte ich die Laufwerke eingeklinkt, erschien auch schon die Nachricht: „Kein Boot-Gerät gefunden, drücken Sie „Strg“ + „Alt“ + „Entf“ für einen Neustart.“ Ich war leicht irritiert, doch nach ein wenig weiterer Recherche hatte ich herausgefunden, dass der traditionelle VMware Server virtuelle IDE-Festplatten verwendete. Bei ESXi steht dagegen nur SCSI als Option zur Verfügung.
Man kann in ESXi zwar durchaus IDE-Geräte verwenden, zum Booten jedoch nur von Medien aus, etwa von CD-ROMs. So war ich also in einer ausweglosen Situation: Ich konnte die virtuelle Disk nicht hochfahren, um die Treiber zum Hochfahren der VM unter ESXi zu installieren, und genauso wenig konnte ich aber die Treiber für die CR-ROM installieren, weil die VM ja nicht starten wollte.
Die VM-Rettung mit VMware vCenter Converter
An diesem Punkt stand ich wirklich kurz vor dem Aufgeben, als mir ein Kollege riet, den VMware vCenter Converter auszuprobieren – ein Tool für das Importieren von VMs anderer Virtualisierungsplattformen. Sonderlich viel Hoffnung hatte ich dabei allerdings nicht.
Mehrere Stunden arbeitete der VMware Converter, bis er schließlich mit der Konvertierung fertig war. Zu meinem großen Erstaunen konnte ich die VM jetzt problemlos importieren und hochfahren.
Um ehrlich zu sein gehöre ich zu den Administratoren, die die Kommandozeile bevorzugen. Trotzdem habe ich Respekt vor dem VMware Converter gewonnen: Das Utility ist äußerst hilfreich und verfügt über viele Optionen, deren Existenz mir bisher verborgen geblieben waren. Auch wenn es streckenweise frustrierend war, half mir diese Wiederbelebung der defekten virtuellen Maschine doch dabei, einige neue Einsichten zu entwickeln.
Erstens: Wer ein auslaufendes Hypervisor-Produkt verwendet, sollte schleunigst auf eines wechseln, das noch aktiv unterstützt wird. VMware Server war kostenlos, aber das gilt für Einprozessor-Maschinen bis heute auch für ESXi. Die Leistung von ESXi ist schon auf Bare-Metal-Bereitstellungen allem deutlich überlegen, was VMware Server heute noch bieten könnte.
Zweitens: Ich weiß heute, dass VMware vCenter Converter ein leistungsstarkes Werkzeug ist, das mir nützlich sein wird, wann immer ich nochmals auf eine ältere virtuelle Maschine stoße, die sich nicht ordentlich importieren lässt.
Und letztlich noch ein Drittes: Diese Erfahrung lehrt uns alle, dass die Verwaltung und Migration einer Umgebung umso teurer und komplizierter wird, je länger sie mit veralteter Software betrieben wird.
Über den Autor:
Stuart Burns ist bei einer Fortune 500 Firma als Virtualisierungs- und Linux-Experte tätig. Sein Spezialgebiet umfasst VMware High Availability Design und Implementierung, Automation und System-Management.
Folgen Sie SearchDataCenter.de auch auf Twitter, Google+ und Facebook!
