Locked Fusion 8.5 .vmdk file running virtual Windows 7 on MacOS Sierra

[GMF]

Embarrassed to say I've got myself into a pickle and hope respondents will be kind to luddite posing as a techie....

I'm trying to deal with a locked VM and cannot find a way around the error "One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot" when trying to resume.  So far, all searches for a solution that works for others are failing me; although, I may simply not be understanding the directions. I have tried deleting .lck files and tried copying my "Window 7.vmdk" file then replacing with copy, but problem persists.

The backstory in case it helps:

I have been reliably running VMWare fusion since 2008 to run a Windows VM on my Mac Pro (early 2008).  I have been keeping the system up-to-date, but the MacOS topped out at Sierra with High Sierra a no go for the early 2008 model. I'm using VMware Fusion 8.5 to run a Windows 7 VM, which I use as my primary work environment.

Today I was deploying a long overdue replacement for the whole computer, so I was trying to backup the old system to prepare for migration.  The new system is not otherwise relevant.  Unfortunately the Mac incurred a hard restart while the VM was open.  Starting Fusion after the reboot triggered an update notification for Fusion and I let it deploy Version 8.5.10 immediately rather than verifying the VM was working.  (Overconfident since I've gotten the error on a hard restart before, but usually I've been able to solve the problem with some reboots and perhaps a deletion of a .lck file.)

The primary 119.48 GB VM file is simply called "Window 7.vmdk" and is located on the same hard drive as the MacOS; however, it is tied to a 383.33 GB VM file called "G-flat.vmdk", which is on a separate hard drive (inside same Mac).

Many thanks in advance for any help.

[a_p_ · Accepted solution]

The issue is likely caused by the fact that the VM was in a paused state, rather to being properly powered off prior to the update.

Assuming that you have a backup (you never know when you need it), you could try to reset the VM, by deleting its suspend state (.vmss) file.

If you are unsure, please provide a complete list of files in the VM's folder/package (with names, sizes, time stamps), and also attach the VM's configuration (.vmx) file as well as the latest vmware*.log file(s) to a reply post.

André

[GMF]

Thanks a.p.!!

Your solution is spot on.

Here is a detailed account that others might find useful (and perhaps you find amusing).

Although I lacked a backup before getting into the suspended state, I backed up the troubled VM and after spending quite a bit of time mulling over your posted solution (Unable to open .vmdk file. One of the disks in this virtual machine is already in use by a virtual m... ) and fiddling, I got it working again this morning after a bit of sleep.   Without that thread, I definitely would have need to ask for more help from your solution on my thread. The stalling point for me was my lack of command line experience in Mac OS.  I couldn't locate the files analogous to those you mentioned in that prior post.  I wasn't working from command line and I didn't realize the Windows 7.vmwarevm file is really a directory with all the files hidden.  I was unfamiliar with the term VMBundle and I had never noticed (let alone used) "Show Package Contents" on a Mac.  (A bit mind boggling since I have used Macs regularly; albeit mostly  mindlessly, since the early 1990's.) 

Since I am more comfortablish in the Windows environment, I finally decided to try using remote access  (GoToMyPC) to transfer the Windows 7.vmwarevm 'file' onto a native Windows box to give it a closer look.  It was good fortune that the GoToMyPC file transfer tool by default showed the hidden files that make up the VMBundle.  I immediately noticed these were the files your prior post referred to, which got me trying to figure out how to see them on the Mac and I found the hidden in plain sight "Show Package Contents".  It took a few attempts to get the correct files since my VM was actually split into multiple .vmdk files, so keeping just the biggest was insufficient.  Thankfully the backed up files allowed me to re-add the critical ones I had mistakenly deleted.

Once I got the bundle down to the correct critical files (in my case:

Windows 7-000005.vmdk

Windows 7-000006.vmdk

Windows 7.vmdk

Windows 7.vmx

Windows 7.vmxf

) the VM was again working nicely.

Thanks again!