Redolog-Fehler mit Bordmitteln beheben:
Vmware-Praxis: Virtuelle Maschine mit fehlerhaftem RedoLog

von Werner Veith (werner.veith@networkcomputing.de), Jake McTigue

Share
16.03.2010

Schließt eine virtuelle Maschine (VM) auf einem Vmware-Server eine Operation wegen zu wenig Plattenplatz nicht ab, hilft es die Snapshot-Dateien zu löschen. Eventuell bootet die VM danach nicht mehr. Dieses Problem lässt sich ohne Restore beheben.

Um Backups von virtuellen Maschinen (VM) zu erstellen, sind Snapshots ein gutes Instrument. Jeder Snapshot verbraucht aber auch entsprechend Speicherplatz. Da kann es gut passieren, dass der Administrator die Fehlermeldung bekommt, dass die VM eine Operation wegen zu wenig Plattenplatz nicht abschließen kann. Also entschließt er sich bei Vmware im »Virtual Infrastructure«-Client (VI) mit Rechter-Maustaste im Kontext-Menü alle Snapshots zu löschen. Doch Vmware kann ihn dabei ziemlich im Regen stehen lassen. Denn es kann passieren, dass das System alle physikalischen Snapshot-Dateien löscht. Nun hat der IT-Verwalter eine VM ohne irgendwelche Snapshots, die sich nicht mehr booten lässt. Will er die betreffende VM starten, bekommt der die Fehlermeldung »The RedoLog für 'SERVERNAME' has been detected to be corrupt. The virtual machine needs to be powered off. If this problem persists, you need to discard the RedoLog.«

Delete-all-Snapshots kann bei einer virtuellen Maschine von Vmware einen unerwarteten Effekt haben. (Quelle: Fotolioa, gunnar3000)

Leider lässt sich der Befehl »remove all snapshots« nicht mehr ausführen, um das RedoLog-Problem zu beseitigen. Denn der Administrator hat den Befehl ja gerade erst ausgeführt, um mehr Plattenplatz zu bekommen. Es gibt eben keine Vmx-Dateien auf dem Speicher mehr und es existieren auch keine Snapshots im Snapshot-Manager mehr. Das Problem lässt sich also nicht mehr über das Interface des VI-Clients beheben.

Um das Ganze wieder ins Lot zu bringen, muss der Administrator zunächst soviel Plattenplatz freimachen, dass er für alle Disks ausreicht, die zu der fehlerhaften VM gehören. Nun muss er sich entweder an die Konsole des ESX-Servers setzen oder eine SSL-Verbindung dorthin aufmachen.

Anschließend geht es in das Verzeichnis auf dem Speicher der betroffenen VM. Die Disks der VM sind dabei fragmentiert und zwar in so viele Dateien, wie es Snapshots gab. Um die Diskdateien zu reparieren, müssen diese fragmentierten Dateien in ein neues File kopiert werden. Das zugehörige Kommando lautet: »vmkfstools -i vmname.vmdk vmname-repaired.vmdk«

Jetzt noch eine Zeile mit dem Editor ändern

Nun erstellt das System eine neue Datei mit den Disks als Klon. Es gibt nun eine Datei »vmname-repaired.vmdk« und »vmname-repaired-flat.vmdk«. Mit einem Linux-Text-Editor öffnet der Administrator nun die originale Vmname.vmx-Datei. Dort gibt es eine Zeile mit »scsi0:0.fileName = 'vmname-00001.vmdk« oder so ähnlich. Nun wird »vmname-00001.vmdk« mit »vmname-repaired.vmdk« ersetzt. Den Klon-Prozess gilt es nun mit allen anderen Disks zu wiederholen, die der VM zugeordnet sind. Nach dem Power-on der VM sollte nun alles laufen.

Es gibt aber auch Fälle, in denen dies nicht funktioniert. Dies kommt vor, wenn die VM-Disk ein Commit auf dem jüngsten Snapshot versucht und dabei scheitert. Dann wird die Snapshot-Datei unbrauchbar. Tritt dies auf, dann wird beim Klon-Prozess ein Fehler auftreten und der Vorgang lässt sich nicht abschließen. Die Lösung ist dann, stattdessen den nächst jüngeren Snapshot zu verwenden.

Hat »vm.vmdk« beispielsweise drei Snapshots, dann ist der Name des ersten »vm-000001.vmdk«, des zweiten »vm-000002.vmdk« und des dritten »vm-000003.vmdk«. Anstatt die Klon-Operation mit der Vm.vmdk-Datei durchzuführen, kommt der zweite Snapshot zum Einsatz. Die Syntax dafür lautet: »vmkfstools -i vm-000002.vmdk vmname-repaired.vmdk«.

Dieses Kommando erstellt aus dem zweiten Snapshot eine einzelne Vmdk-Datei. Diese lässt sich nun in die Vmx-Datei eintragen. Dabei gehen zwar Änderungen im jüngsten Snapshot verloren. Dies ist aber der einzige Weg, eine korrupte Vmdk-Datei wieder herzustellen, ohne ein Backup zu verwenden.
Verwandte Artikel