When your virtual machine suddenly goes on “strike” in the middle of the night
A familiar scenario: The clock strikes 2 AM, and you’re grinding through a deadline or configuring a web server on VMware. Suddenly, the power flickers or Windows decides to restart for an update. After the reboot, you open VMware hoping to pick up where you left off, only to be met with a cold splash of water: “The virtual machine is in use” or “Taking ownership of this virtual machine failed”.
It’s a real pain! You know for a fact that no one else is using this VM, yet VMware insists it’s locked. With experience running clusters of over 10 ESXi hosts and managing hundreds of VMs, I encounter this situation quite often. This error is actually just a self-protection mechanism of VMware, and it’s not scary at all once you understand how it works.
The File Locking Mechanism: Why does the VM “lock itself”?
Before diving into the fix, let’s understand the root of the problem. VMware uses a File Locking mechanism to ensure data integrity. When you Power On a virtual machine (VM), the system creates folders or files with the .lck (Lock) extension within the VM’s directory.
This is VMware’s way of “claiming ownership.” It prevents two different VMware processes from writing data to the same virtual disk file (.vmdk) simultaneously. Without this mechanism, data would be overwritten randomly, leading to total OS corruption (data corruption) in an instant.
Normally, when you shut down a VM properly, VMware automatically cleans up these .lck files. However, if your computer loses power suddenly or the vmware-vmx.exe process is killed unexpectedly, these “remnants” stay behind. When you reopen it, VMware sees the old lock file and mistakenly thinks the VM is running elsewhere, resulting in access being denied.
A 4-Step Process for Safely Handling .lck Files
Don’t rush to reinstall the VM or ghost Windows just yet. Stay calm and follow this field-tested procedure.
Step 1: Clean up hung processes
Sometimes the VM isn’t actually off but is still running in the background as a hung process. On Windows, press Ctrl + Shift + Esc to open Task Manager.
- Switch to the **Details** tab.
- Find and terminate processes:
vmware.exe,vmware-vmx.exe,vmware-authd.exe. - Right-click and select **End Task** to ensure nothing is still holding the files.
If you are using Linux or SSHing into an ESXi host, use this “powerful” command:
# Find the PID of the hung virtual machine
ps aux | grep vmx
# Force kill the process (replace PID with the actual number, e.g.: kill -9 1234)
kill -9 <PID>Step 2: Identify the exact “scene”
If you don’t remember where the VM is stored, look at the path in the error message. Usually, these files are located in C:\Users\[Username]\Documents\Virtual Machines\.... Navigate to that exact folder using File Explorer.
Step 3: Delete the .lck folders
Inside the VM folder, you will see several folders with names ending in **.lck**. For example, for a VM named Ubuntu-Dev, you might see Ubuntu-Dev.vmdk.lck or Ubuntu-Dev.vmx.lck.
Action: Select all folders with the .lck extension and press Shift + Delete.
Red Alert: Only delete folders/files with the .lck extension. Absolutely do NOT touch .vmdk (virtual disk), .vmx (configuration), or .vmsd (snapshot) files. Deleting a vmdk file by mistake means losing all your data with no way to recover!
Step 4: Verify the results
After the cleanup, reopen VMware Workstation and restart the VM. In 99% of cases, the machine will start up smoothly as if nothing ever happened.
Pro-tip for ESXi Cluster Environments
In a production environment, sometimes the vSphere Client won’t let you delete a lock file because it’s being held by the Host’s Kernel itself. In these cases, I often use the vmfsfilelockinfo command to track down the “culprit” (the MAC address of the host holding the lock):
vmfsfilelockinfo -p /vmfs/volumes/DATASTORE_NAME/VM_NAME/VM_NAME.vmdkOnce you know which host is holding the file, simply restart the management services on that host; this won’t affect other running VMs:
/etc/init.d/hostd restart
/etc/init.d/vpxa restartHard-learned lessons to avoid the error
Instead of clicking the X button and selecting “Power Off” (which is like pulling the plug), get into the habit of shutting down from within the Guest OS. This gives VMware enough time to close file descriptors and cleanly delete the lock files.
Another cause that few people notice is Disk Full. When the physical hard drive is full, VMware cannot write temporary files, leading to hung processes and stuck locks. Always ensure there is at least 10-20GB of free space for the system to “breathe”.
Conclusion
The “The virtual machine is in use” error sounds serious, but it’s really just some leftover metadata. By mastering the .lck file removal process, you’ll have full control over your virtual machines. I hope this “night shift” experience helps you avoid some headaches when issues arise.
