Die Tage kam ein Kollege auf mich zu, “Du, ich hab da ne VM die ich nicht mehr einschalten kann.” Des Weiteren zeigte vSphere an dass für die VM eine Konsolidierung der Snapshots nötig sei, was mit der gleichen Fehlermeldung fehl schlug.
Failed to open ‘/vmfs/volumes/datastore/vm/vm-000004.vmdk’ with flags 0xa The system cannot find the file specified (25).
Sie beschwerte sich dass eine .vmdk-Datei nicht vorhanden sei, ein kurzer Blick auf den Datastore zeigte jedoch dass die Datei vorhanden war.
Bei der Suche nach dem eigentlich Grund stieß ich zuerst auf diesen KB-Artikel:
Anscheinend war die VM irgendwann mal unter VMware Workstation angelegt worden und die Festplatten waren in einem Format mit dem ein moderner ESXi-Server nichts mehr anfangen kann.
Das dort benutzte Tool vmkfstools hat aber noch ein paar weitere interessante Funktionen. Unter anderem lässt sich bei Snapshots prüfen ob die Snapshot-Kette gültig ist und die .vmdk-Dateien auf Fehler überprüfen. bei der Überprüfung der Haupt-vmdk-Datei gab das Tool dann diese kuriose Fehlermeldung aus:
/vmfs/volumes/datastore/vm # vmkfstools -x check vm.vmdk Disk needs repair. Disk has scary/unexplainable errors.
Okay. Dafür dass die Disk scary/unexplainable errors hatte ließ sie sich dann aber mittels vmkfstools -x repair erstaunlich problemlos reparieren. Zumindest in der Theorie, Einschalten ließ sich die VM danach immer noch nicht.
Also doch noch die Konvertierung der Platten ins korrekte Format durchführen. Erschwert wurde das ganze dadurch, dass die VM vier Snapshots hatte, wodurch sich die Konvertierung nicht direkt durchführen ließ. Ich musste erst die Basis-Disk konvertieren und im Anschluss danach den aktuellsten Snapshot. Die restlichen noch vorhandenen Snapshots wurden dadurch ungültig und ich musste sie wegwerfen.
Die VM bootete danach dafür wieder.
Ganz wichtig: Vor solchen Versuchen die komplette VM einmal sichern (geht ganz einfach direkt auf dem Server mit tar), ich musste die VM bei meinen Versuchen mehrfach wiederherstellen.