A few weeks back, I was performing a cold migration (moving virtual machines between clusters and data stores). One of the migrations failed which resulted in an apparent lock of one of the two vmdk’s assigned to the machine. Neither side of the VM equation would start. Both the source and destination VM’s issued errors Unable to access a file since it is locked. The solution was not easily gleaned by the situation. There were no processes assigned to the VM on the cluster members, and running the assorted list of CLI did not show the cause.
My esteemed colleague, VMwise, swooped in and worked some magic. After some fiddling, he issued a vmkfstools -L targetreset /vmfs/devices/disks/vmhba0:x:y:1 where X is the target, and Y is the LUN ID. So, if you have 4 LUNs that make up your datastore, and their LUN ID’s are 4, 5, 6, 7, and your target is 1, you would need to issue the following commands:
vmkfstools -L targetreset /vmfs/devices/disks/vmhba0:1:4:1
vmkfstools -L targetreset /vmfs/devices/disks/vmhba0:1:5:1
vmkfstools -L targetreset /vmfs/devices/disks/vmhba0:1:6:1
vmkfstools -L targetreset /vmfs/devices/disks/vmhba0:1:7:1
Once that was done, the target lock was reset, and both sides of the operation “completed.” By that I mean the source vmdk was unlocked, and the destination VM was deleted by the cold migration process since it did not complete.