Lässt sich z. B. eine virtuelle Maschine nicht starten, kann das daran liegen, dass für die betreffende VM Files-Locks existieren. Warum?

Beim Einschalten einer virtuellen Maschine werden so genannten Lock-Files generiert. Das Verfahren gewährleistet die Konsistenz der virtuellen Disks. Würde eine VM keine File-Locks verwenden, könnten mehrere Prozesse gleichzeitig auf der gleichen vDisk zu lesen und schreiben versuchen. Lock-Dateien werden stets im gleichen Verzeichnis angelegt, in dem auch die die eigentliche VMDK-Datei liegt. Beim Ausschalten der VM, werden Lock-Files im Normalfall wieder aufgelöst.

Stale Lock Files

Kann eine VM die eigenen Lock-Files beim Ausschalten allerdings nicht entfernen, bleibt ein Stale-Lock-File zurück, das die vorhandene VMDK-Datei schützt. Das kann z. B. passieren, wenn der ESXi-Host abstürzt und die VM keine Chance hat, das Lock-File ordnungsgemäß zu entfernen.

Lock-Files gibt es nicht nur zum Schutz der VMDK-Datei einer virtuellen Maschine, sondern auch für anderen VM-Files. Sind aber eine oder mehrere-VM-Files gesperrt, lässt sich die betreffende VM eben nicht mehr neu einschalten.

Wer ist Schuld ?

In einem Cluster-Szenario mit Shared Storage muss man für das Auflösen eines solches Zustandes zunächst herausfinden, welche ESXI-Host für die Locks verantwortlich ist. Ist man per ESX-Shell oder SSH auf dem betreffenden Host, klappt das klappt z. B. mit Hilfe des CLI-Tools vmkfstools.

vmkfstools -D /vmfs/volumes/Shared/<Name-der-VM>/<Name-der-VM>-flat.vmdk

Mit

lsof | grep <Name der gelockten Datei>

könnte man dann ermitteln, welcher Prozess für das Lock verantwortlich ist und dieses dann auf der Kommnadozeile mit killen, z. B. mit …

esxcli vm process list
esxcli vm process kill –w <wold-id>