Manchmal konsolidieren Consolidation-Helper Snapshots von Backup-Programmen nicht korrekt. Wenn das nicht auffällt, landen bei jedem neuen Consolidation-Helper neue zusätzliche .vmdk-Dateien im Dateisystem:
Diese fressen nach und nach den freien platz im Datastore auf und sind in der Snapshot-Ansicht nicht zu sehen:
Sobald man im Gast-Menü „Konsolidieren“ auswählt erscheint folgende Fehlermeldung im Log:
Zugriff auf die Datei <unspecified file> nicht möglich
… oder deren Englischsprachiger pendant:
Unable to access file <unspecified filename> since it is locked
Die Ursache sind in der Regel VADP (vmware api for data protection) Backups, bei denen beim zurückrollen der Helpersnapshots ein Fehler aufgetreten ist.
Lösung
- Backup-Jobs abschalten. Wenn wärend des manuellen zurückrollens ein VAPD-Helper gestartet wird, ist die zerstörung der VMDK warscheinlich.
- Prüfen, welche VMDK die letzte erstelle ist. Achtung! Die Datei mit der höchsten Nummer ist nicht zwingend die letzte. Das geht in der Bearbeitungsansicht des Gastsystems:
Öffnen einer SSH-Shell auf den Server, die diese Maschine registriert hat (verschieben ist vorher möglich) und wechseln in das Verzeichnis in dem die betreffende Maschine wohnt (z.B. /vmfs/volumes/4444444-4444444-4444-f4f4f4f4/meinemaschine/)- Herunterfahren des Gast. Das ist wichtig, weil die VMDK nur offline vollständig zurückrollt wenn die VADP nicht mehr funktionieren.
- Zurückrollen (Klonen) der Snapshots mit vmkfstools in eine neue VMDK:
vmkfstools -i meinemaschine-0000??.vmdk ./NEWdisk1.vmdk
Die „??“ entsprechen dem letzten Snapshot aus dem zweiten Punkt. Anstelle des aktuellen Pfades („./“) kann auch ein anderer Datastore zum Beipisle mit mehr Platz verwendet werden. Dieser vorgang dauert eine (ganze) Weile.
- Jetzt wird eine neue VMDK erstellt, die einfach an die Maschine anstelle der alten angehängt wird. Die MAschine dann nun noch testen und wenn alles läuft die alten -0000* Snapshots löschen.
Das klappt alles sehr gut, solange es keinen I/O-Error im zugehörigen vmware.log gibt. Wenn das der Fall ist, ist die integrität mindestens einer .vmdk beschädigt; sofern die VM dann noch läuft klappt eigentlich nur noch ein Converter-Klon. Es sei denn jemand hat einen noch besseren Tipp für uns 🙂
Lebensretter, danke!!!!!
Danke, hat mir den Arsch gerettet!
bei mir lag es daran, dass der Server welcher die Backups durchführt, die vmdks immernoch gemountet hatte. deshalb die „is locked“ meldung.
nachdem ich die vmdks getrennt hatte, konnte ich auch die konsolidierung durchführen.
danke für den tipp damit hab ich mir viele stunden erspart