Hello experts and other experienced users,
I'm going my first experimental steps in administration of non-interactive VMs under VMware Workstation 7.1.4 on a Windows 7 (Prof. 64 Bit SP1) host using the vmrun utility. Beginning with a clean VM file set, I called
vmrun -T ws start myvm.vmx nogui.
The VM ran fine. Then I tested to finish VM’s execution either by powering down or by suspending it, like this:
vmrun -T ws stop myvm.vmx soft
vmrun -T ws suspend myvm.vmx.
Then I started the VM again by the command mentioned first, etc. All those start-stop/suspend cycles did work with no obvious problems. But a more detailed analysis disclosed a remarkable effect. The stop as well as the suspend operation leave the myvm.vmx.lck subdirectory in place. In other words, those operations seem to disregard an ordinary closing of the VM, at the end of their execution. (To avoid misunderstanding, only vmx.lck persisted. All other types of lck subdirectories vanished, as expected.)
On the contrary, the lck relict did not remain in place if the VM was previously started with Workstation GUI, like this:
vmrun -T ws start myvm.vmx gui.
Even with absolutely no user interaction via the Workstation GUI, the stop/suspend operations mentioned above did NOT leave the myvm.vmx.lck.
So, the behavior of vmrun’s stop/suspend operation depends on the gui/nogui argument at the start operation. The question is: bug or “works as designed”? I didn’t find any reason for “works as designed”, so far.
The lck relict seemingly doesn’t cause problems, in practice. Has anybody other experience? So, my primary intention of this posting is to achieve clarity and understanding in order to ease development and testing of real life solutions.
if you want a reliable script I would use a line to delete eventual left over lock files and directories