Tja es hätte so einfach werden können. Da heute Abend noch etwas Zeit war, dachte ich, jetzt wo die Besucherzahl gering ist, schnell die Zeit nutzen und den in den letzten Wochen langsam an der Last zu erdrücken drohenden Intranet-Webserver, welcher natürlich unter VMWare ESX läuft, vergrössern. Konkret wollte ich den RAM von 2GB auf 4GB und die CPU Anzahl von 2 auf 4 erhöhen. Um die Downtime zu überbrücken habe ich also am vorgelagerten »Apache« auf den Backupserver umgeschaltet und meinen unter »Ubuntu Hardy« laufenden Apache- und MySQL-Server neu gestartet. Doch was ist jetzt? »fsck« hängt bei 14% fest und die VM ist nicht mehr bedienbar, weder ein Reset noch ein PowerOff möchte gelingen. Ein kurzes Warten, ob sich die Situation von alleine auflöst, bliebt leider ohne Erfolg. Wie bekomm ich den Prozess jetzt beendet, es laufen ja noch einige weitere VMs auf dem ESX-Host. Kein Problem, einfach per SSH auf die ESX-Konsole und die »PID« des hängenden Prozesses heraussuchen:

»-ww« steht für »wide output« und bewirkt hier doppelt angewandt, dass die Prozess-Zeile komplett angezeigt wird. Nötig wird das, da der Name der VM erst am ganz am Ende der Ausgabe erscheint. Wenn die VM also tatsächlich läuft, was bei mir zum Glück der Fall war, dann sollte die Ausgabe wie folgt aussehen:

Die in der Ausgabe angezeigte PID, in diesem Beispiel »3860« wird einfach über ein:

terminiert. Bei mir war die Option »-9« aber noch nicht einmal nötig.

Gut nun folgte noch ein weiterer Versuch, allerdings hing »fsck« hier erneut, so dass ich versucht hatte die VM über das Virtual Center zu clonen. Der Clone zog sich hin (~1Std), wurde aber erfolgreich erstellt - beim Starten allerdings das Gleiche: »fsck« hängt, die CPU-Auslastung der VM liegt dabei bei 100%. 10 Minuten warten, aber nichts passiert.

Die nächste Idee also, eine neue HDD an die VM hängen und mittels Knoppix die Daten übertragen und das scheinbar defekte »VMDK« entsorgen. Ein Fehler im VMFS bzw. auf dem gesamten Datastore schloss ich aus, da der Clone bereits auf einem anderen Bereich erstellt wurde. Unter Knoppix lief das »fsck« übrigens durch, auch die VM lief hinterher wieder hoch und schien in Ordnung. Da die VM aber nach einem Stromausfall schon einmal Probleme gemacht hatte (der Snapshot vom vRanger-Backup konnte nicht wieder entfernt werden) habe ich die Platte unter Linux mit Hilfe von »rsync« geclont und das alte VMDK prophylaktisch doch komplett entsorgt.