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!!!!!