Unable to open file .vmdk. One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot.

[MBHkewl]

Hello,

I've gone through some of the forum links around (mainly this), but unfortunately I wasn't able to have my VM work. I'm almost done with my bootcamp's final project and now all files are gone, so help is highly appreciated...

I'm using Workstation Pro 15.5 and have been running this VM since September. I've enabled AutoProtect on it with hourly snapshots, up to 3. Yesterday, Windows 10 decided to put the laptop to standby, when I woke it up, it gave me a Blue Screen of Death (BSOD), crash dumped, and rebooted. After the reboot, I was unable to power on my VM, with the error message: "Unable to open file .vmdk.  One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot."

When I first checked the VM's settings in the UI, it was pointing the disk at coded-debian-0001.vmdk rather than the main vmdk file. I tried changing that and pointing it elsewhere, but the same error kept showing.

I've attached the directory structure and file output, among other files. There were lock files and whatnot. I copied the VM's folder and played with the original (the copy is intact). I tried removing all lock files, but that didn't help. I tried using the vdiskmanager -r option on the main .vmdk and on the snapshots' .vmdk but it always produced a .vmdk that points at the first disk of the VM, not the latest one or near latest. Then I tried the option -R on each vmdk (main and snapshots) and it found that 0002.vmdk was corrupted and fixed it, however, I was still unable to power on the VM.

If it's of any importance, my laptop uses an NVMe, and when it restarted, I ran a filesystem check, but Windows reported that no errors were found. Also, the VM was idle and no files were being written to, though there were open files at the time.

Thank you.

[a_p_]

Autoprotect may be something to help reverting to a previous state, but it doesn't replace backups.

Anway, to get an overview of what's damaged, and what can be done, please download dsfok.zip from http://faq.sanbarrow.com/index.php?action=artikel&cat=47&id=111&artlang=en, extract the executables, run the below command in the VM's folder, then compress/zip all the "xxx-....bin" files and attach the .zip archive to a reply post.

for %i in (*.vmdk) do @dsfo.exe "%i" 0 2686976 "xxx-%~ni.bin"

The command will extract only metadata (i.e. no user data) from the .vmdk files.

When I first checked the VM's settings in the UI, it was pointing the disk at coded-debian-0001.vmdk rather than the main vmdk file. ...

VMs with snapshots always point to the latest snapshot .vmdk file, and never to the base disk. Did you backup the VM's files before, or after you modified the .vmx file, i.e. do you have a backup of the main .vmdk file before you changed anything?

André

[MBHkewl]

Thank you very much for the reply, Andre.

I've attached 2 files: one from the VM folder after I ran the vmdisk -R (repair) option, and the other is before running the repair (Copy 2).

To answer your question: Unfortunately, I backed up/copied the VM folder after I made the first change to the VMX, but before touching any other file.

[a_p_ · Accepted solution]

I checked the files, and some of them (1, 2, and 5) are either blank (all zeroes), or corrupted. However, the 3 large files (base, 3, and 4) seem to be ok from a metadata point of view. There may however remain some corruption due to the fact that the base disk has been modified by powering the VM on using it.

1. inject the attached binary into the corresponding .vmdk file to fix the snapshot chain
   dsfi.exe "coded-debian-000003.vmdk" 0 2686976 "fixed-coded-debian-000003.bin"
2. create a new subdirectory, e.g. "repair"
3. clone the 3 large .vmdk files into a new .vmdk file (make sure that you specify the newly created directory for the target !!!)
   vmware-vdiskmanager.exe "coded-debian-000004.vmdk" -t 0 "repair\coded-debian.vmdk"
4. copy the VM's .vmx file to the newly created directory
5. edit the .vmx file, so that it contain the cloned .vmdk file's name
6. optional, for better overview - remove (don't delete from disk) any other "coded-debian" VMs from VMware Workstation's library
7. add the edited .vmx to the library
8. change the VM's settings and disable Auto-Protect !!!
9. create a snapshot, so that the current files won't get modified
10. power on the VM, and - if asked whether the VM has been copied, or moved - answer the question with "I moved it"

André

[a_p_]

...just to clarify. I've used the provided "coded-debian - Copy (2).zip" as the base for the above steps.

André

[MBHkewl]

Thank you again, Andre.

I've followed the steps:

dsfi.exe "coded-debian-000003.vmdk" 0 2686976 "fixed-coded-debian-000003.bin"

OK, written 2686976 bytes at offset 0

vmware-vdiskmanager.exe -r "coded-debian-000004.vmdk" -t 0 "repair\coded-debian.vmdk"

vmware-vdiskmanager.exe -r "coded-debian-000004.vmdk" -t 0 "repair\coded-debian.vmdk"

Creating disk 'repair\coded-debian.vmdk'

FILE: FileLockMemberValues removing problematic lock file 'coded-debian - repairing\coded-debian-000004.vmdk.lck\M08529.lck'

FILE: FileLockMemberValues removing problematic lock file 'coded-debian - repairing\coded-debian-000003.vmdk.lck\M23898.lck'

  Convert: 87%

done.Virtual disk conversion successful.

I removed existing VMs from the library and mounted/opened the newly repaired one. However, I couldn't power it on.

EFI boot says:

EFI VMware Virtual SCSI Hard Drive (0.0)... No compatible bootloader found.

I have a Debian ISO, so I booted the VM with it into rescue mode to see if the files are there, and I did find the files, but unable to boot the VM itself.

[a_p_]

Not sure what's causing this.

Does trying to boot the VM create a new vmware.log file? Maybe it contains hints!?

Although I don't think that it will make a difference, please copy the VM's "old" .nvram file over to the new/current directory.

André

[MBHkewl]

I saw some errors in the new log file (attached). Mainly these lines:

2019-12-27T16:45:42.009+03:00| vmx| A100: ConfigDB: Setting scsi0:0.redo = ""

2019-12-27T16:45:42.009+03:00| vmx| I125: DISK: OPEN scsi0:0 'C:\Users\mj\Documents\Virtual Machines\coded-debian - repairing\repair\coded-debian-000001.vmdk' persistent R[]

2019-12-27T16:45:42.009+03:00| vmx| I125: DISKLIB-DSCPTR: Opened [0]: "coded-debian-000001.vmdk" (0xa)

2019-12-27T16:45:42.009+03:00| vmx| I125: DISKLIB-LINK  : Opened 'C:\Users\mj\Documents\Virtual Machines\coded-debian - repairing\repair\coded-debian-000001.vmdk' (0xa): monolithicSparse, 41943040 sectors / 20 GB.

2019-12-27T16:45:42.024+03:00| vmx| I125: DISKLIB-DSCPTR: Opened [0]: "coded-debian.vmdk" (0xe)

2019-12-27T16:45:42.024+03:00| vmx| I125: DISKLIB-LINK  : Opened 'C:\Users\mj\Documents\Virtual Machines\coded-debian - repairing\repair\coded-debian.vmdk' (0xe): monolithicSparse, 41943040 sectors / 20 GB.

2019-12-27T16:45:42.024+03:00| vmx| I125: DISKLIB-LIB   : Opened "C:\Users\mj\Documents\Virtual Machines\coded-debian - repairing\repair\coded-debian-000001.vmdk" (flags 0xa, type monolithicSparse).

2019-12-27T16:45:42.024+03:00| vmx| I125: DISKLIB-LIB_MISC   : DiskLib_GetStorageBlockSizes: Failed to get storage block sizes, The virtual disk requires a feature not supported by this program.

2019-12-27T16:45:42.024+03:00| vmx| I125: DiskGetGeometry: Reading of disk partition table

2019-12-27T16:45:42.024+03:00| vmx| I125: DISK: Disk 'C:\Users\mj\Documents\Virtual Machines\coded-debian - repairing\repair\coded-debian-000001.vmdk' has UUID '60 00 c2 9f 07 08 2c fa-d6 c3 1a 53 17 81 23 b7'

2019-12-27T16:45:42.024+03:00| vmx| I125: DISK: OPEN 'C:\Users\mj\Documents\Virtual Machines\coded-debian - repairing\repair\coded-debian-000001.vmdk' Geo (2610/255/63) BIOS Geo (0/0/0)

2019-12-27T16:45:42.024+03:00| vmx| I125: DISKLIB-LIB_MISC   : DiskLibEnumExtentsFromInfo: expecting 1 link; got 2

2019-12-27T16:45:42.024+03:00| vmx| I125: DISK:DiskAutoDetectVirtualSSD: Failed to enumerate disk: 'C:\Users\mj\Documents\Virtual Machines\coded-debian - repairing\repair\coded-debian.vmdk'. Reason: One of the parameters supplied is invalid.

However, when I copied the nvram file of the original VM, it booted just fine! Maybe because I'm using EFI and not BIOS? Whatever it is, it's working now and I have my files and a functioning VM.

Should I clone this VM into a new VM?

[a_p_]

I'm glad to see that the VM is working again. Thank's for the feedback.

Should I clone this VM into a new VM?

No need to do this. The VM that you now have is not different from a newly created one. Just make sure that you backup the VM from time to time, and don't keep snapshots longer than required.

André

[MBHkewl]

Much appreciated.

I've done data recovery before, but from filesystems and devices, never on VMs. I saw your replies to previous threads, but didn't understand the tools' usage or how you chose the numbers.

Is there a guide for me to read somewhere on how to recover damaged VMs? I'd like to learn more about the process.

[a_p_]

I'm not aware of a repository that covers everything, because things differ between VMware products, and file types.

However, if you are interested in how the metadata within .vmdk files looks like, then https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf  might be a good start.

Another great resource is https://sanbarrow.com/vmdk-handbook.html​.

It's likely not necessary to say that most cases are different, so that there's no rule of thumb that one can follow.

André