Could not open virtual machine

VMware Error: Could Not Open Virtual Machine – Fix Guide

Server & Cloud Intermediate 👁 14 views 📅 Jun 26, 2026

This error pops up when VMware can't read the VM's files. Usually it's a permissions or lock file issue. Here's how to fix it quick.

You walk into the office, sip your coffee, hit the power button on your VMware Workstation or ESXi host – and bam. Error pops up: "Could not open virtual machine." The VM just sits there grayed out. Maybe you see a lock icon, maybe not. This happens a lot when someone shut down the VM wrong, or the host crashed. Had a client last month whose whole lab died because their ESXi host lost power, and this error hit all six VMs.

The root cause is almost always one of two things: a stale lock file or a permission mismatch. VMware uses a lock file (ends in .lck) to stop multiple hosts from opening the same VM at once. If the host crashes, that lock file doesn't get cleaned up. So VMware sees the lock, thinks another process is using the VM, and refuses to open it. The other common cause – Windows or Linux permissions on the VM folder got messed up, maybe from a backup restore or a user copying files manually.

Quick Fix: Remove Lock Files

This is step one, and it works 90% of the time.

  1. Shut down the VMware host or close VMware Workstation completely. Don't skip this or the lock file won't release.
  2. Navigate to the folder where your VM lives. For Workstation, that's usually C:\Users\[YourName]\Documents\Virtual Machines\[VM Name]. For ESXi, it's the datastore, like /vmfs/volumes/datastore1/[VM Name]/.
  3. Look for any files or folders ending in .lck. Examples: vmname.vmx.lck or vmname.vmdk.lck. Delete them. Yes, delete. VMware will recreate them on next power-on. (On ESXi, use the datastore browser in the vSphere client.)
  4. Now open the VM. It should work. If not, go to step two.

Check Permissions on the VM Files

If lock files didn't fix it, the VM's file permissions are probably wrong. This is common after a backup restore where the software changed ownership.

  1. Right-click the VM folder (not the files inside yet) and go to Properties.
  2. Security tab. Check the user or account that runs VMware (usually SYSTEM, Administrators, or your user). Make sure it has Full Control. If it's missing, click Edit, add the user, grant Full Control.
  3. Click Advanced, then enable "Replace all child object permission entries." Apply and wait. This resets permissions on every .vmx, .vmdk, and .nvram file.
  4. For ESXi, permissions work differently. In the datastore browser, right-click the VM folder, select Properties, check the owner. It should be root or vpxuser. If it's something else, SSH into the host and run: chown -R root:root /vmfs/volumes/datastore1/[VM Name]/.
  5. Try opening the VM again.

Run a Disk Check on the VM's VMDK

Permissions clean? Lock files gone? Still broken? The .vmdk file itself might be corrupt. This is rarer, but after a hard crash it happens.

  1. In VMware Workstation, go to File > Map Virtual Disks. Select the .vmdk file. If it maps fine, the disk is probably okay – skip this.
  2. If it fails, you need to run fsck (Linux) or chkdsk (Windows) on the VM's virtual disk. But you can't do that from inside the broken VM. Use a rescue ISO disk or boot the VM from a Linux live CD, then run fsck /dev/sda1 (or whatever partition). For Windows VMs, boot from a Windows installer disk and run chkdsk /f from the recovery console.
  3. If even that fails, your last shot is VMware's vmware-vdiskmanager command. On a Windows host, open a command prompt as admin, go to VMware's install folder (usually C:\Program Files (x86)\VMware\VMware Workstation), run: vmware-vdiskmanager -R "[path to your .vmdk]". The -R flag repairs the disk header. This saved my bacon on a server VM that wouldn't boot.

Still No Luck? Check These

If you've done all three steps and the VM still won't open, you're in a deeper hole. Here's what to try next:

  • Check if the VMX file got corrupted. Open the .vmx file in Notepad, look for any line that says mks.enable3d = "TRUE" and set it to "FALSE". Had a client whose VMX file had a stray unicode character from a copy-paste error. Fixed it by deleting lines one by one until it worked.
  • Try importing the VM into a different version of VMware. Sometimes a VM created in Workstation 16 won't open in Workstation 15. Use the wizard: File > Import/Export.
  • Look at the VMware logs. In the VM folder, open vmware.log with Notepad. Near the end, you'll see the exact error. It might say something like "Failed to lock the file" or "Permission denied." That tells you exactly what's wrong.
  • Last resort: Create a new VM with same hardware settings, then attach the old .vmdk as a second disk. Boot the new VM, copy data off if you can.

Don't spend hours reinstalling VMware. Nine times out of ten, it's a damn lock file or a permission that got reset by a backup. Start with those two, and you'll be up and running in five minutes.

Was this solution helpful?