Startseite > Software & Services > Vmware-Praxis: Virtuelle Maschine mit fehlerhaftem RedoLog

Redolog-Fehler mit Bordmitteln beheben

Vmware-Praxis: Virtuelle Maschine mit fehlerhaftem RedoLog

16. März 2010, 13:12 Uhr | Werner Veith

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

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.«

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«