I have been using VM Workstation Player 15 on Windows 10 for many years. Great product!
I recently had to create more space on my host hard disk. I deleted a few of the oldest snapshot files thinking they didn't matter. They did.
I now cannot start my VM anymore: "Cannot open the disk 'C:\Users\[user]\Documents\Virtual Machines\[name]\[name]-0.vmdk' or one of the snapshot disks it depends on."
There are still a few [name]-s***.vmdk and [name]-0-s***.vmdk files left. Is it possible to use these to restore the VM, or at least some of its data?
Attached is a recent log.
Thanks for your help.
Since you got no answers, I will give you a speculative, principal answer. I don't have any internal information on Snapshots.
Snapshots are an incremental way of preserving states of the computer. They must be incremental, because snapshot is much smaller than the actual computer at the time of creating a snapshot. So, a snapshot saves information on files, which have been deleted, created or modified after the last known position. Thus, they for a continuous flow of states. If you loose (in an uncontrolled way) any one of them, the continuos flow is broken.
You cannot know from any later status, what the history - in terms of file existence, modification status or deletion - has been in the past. Neither can you predict the future, from any earlier state.
You obviously shouldn't delete any of these files with a File Manager/Explorer. You CAN delete snapshots using Snapshot Management Tools, which takes care of preserving the logic, mentioned in the Item 1 above. Deleting a snapshot with Tools, takes a considerable amount of time, as can be predicted based on the logic.
Having said that, if you could get rid of ALL the snapshots and their internal configuration, then your current state of the computer could perhaps be saved. But I have no idea how that can be done manually and IF there is a feasible way to do this. I'm not saying this is possible at all, because even the current state could be dependent on snapshot content.
I hope some VMware guy could give an explicit answer on this.
What exactly did you delete? AFAIK VMware Player doesn't support snapshots, so it's likely some of the base files which got deleted.
To find out what may be possible, please run dir *.* /one in the VM's folder, and post the output in your next reply.
Yes, of course. My answer was based on the assumption that you are actually using VMware Workstation Pro and not Player. Or at the minimum the VM computer has previously been used by Workstation Pro.
Thank you for reaching out and your detailed answer.
I'm indeed using (and have ever only used on this host) Workstation Player.
I will continue the thread with Andre. Hopefully that can lead to a solution.
I have deleted files from the directory C:\Users\[user]\Documents\Virtual Machines\[VM_name].
It contains among other things a number of [VM_name]-s***.vmdk files and [VM_name]-0-s***.vmdk. Most (but not all) of these files have a size of 4.1 GB.
I deleted some of the oldest of these 4GB vmdk files. The files I still have in this directory are:
26/11/2020 13:57 668 MITM SD
15/04/2021 11:30 8,684 MITM tester.nvram
15/04/2021 11:25 738 MITM tester.vmdk
14/05/2020 23:06 0 MITM tester.vmsd
15/04/2021 13:30 3,427 MITM tester.vmx
04/11/2020 16:32 369 MITM tester.vmxf
15/04/2021 11:40 1,013 MITM tester-0.vmdk
15/04/2021 13:27 4,006,543,360 MITM tester-0-s001.vmdk
15/04/2021 13:27 4,125,556,736 MITM tester-0-s003.vmdk
15/04/2021 13:27 4,199,612,416 MITM tester-0-s004.vmdk
26/11/2020 13:51 165,150,720 MITM tester-0-s006.vmdk
23/11/2020 22:13 160,497,664 MITM tester-0-s012.vmdk
15/04/2021 13:27 4,206,428,160 MITM tester-s001.vmdk
15/04/2021 13:27 4,252,762,112 MITM tester-s002.vmdk
15/04/2021 13:27 4,232,904,704 MITM tester-s003.vmdk
15/04/2021 13:27 4,245,159,936 MITM tester-s004.vmdk
15/04/2021 13:27 4,224,188,416 MITM tester-s005.vmdk
07/12/2020 11:47 166,789,120 MITM tester-s006.vmdk
01/12/2020 21:21 <DIR> New folder
20/04/2021 12:35 66,472 vmware redacted.log
20/04/2021 12:37 11,436 vmware redacted.zip
20/04/2021 12:09 66,924 vmware.log
15/04/2021 13:51 66,396 vmware-0.log
15/04/2021 13:50 66,395 vmware-1.log
15/04/2021 13:35 66,351 vmware-2.log
25/05/2020 13:37 0 vmware-vmx.dmp
Does that help?
By default virtual disks are split into multiple sparse files "...-s0xx.vmdk", where each of these files contain data blocks that are logically mapped to a certain location on the disk. The required files which make up such a virtual disk are listed in the header/descriptor .vmdk files, i.e. the ones without "-s0xx" in their file names. The individual .vmdk files are only updated if writes go to guest OS data blocks that are backed by these files, that's why they may have different time stamps.
According to the file listing that you've provided, the VM has two virtual disks. The first one "MITM tester.vmdk" (20GB) seems to ok, but the second one "MITM tester-0.vmdk" (likely ~40GB, resized from originally 20GB) has missing files.
There's basically no way to restore data that had been backed by these files, except for restoring these files from a backup (which I assume you don't have) or some data recovery tool. However, what I offer you, is to provide you with suitable stub files, so that it should be possible to bring up the VM, and allow you to try and recover some of the guest's files which are still intact.
If you'd like me to create such stub files for you, then compress/zip the "MITM tester-0.vmdk" header file, and attach the .zip archive to your next reply. Alternatively, you may simply paste the contents of the header file (which is a text file) in your next reply.
While I'm creating the stub files, please consider to backup the VM's current folder/files, so that you can at least revert to the current state in case it's necessary.
The attached archive contains stub files for the missing .vmdk files. With these files in place VMware Player should recognize the virtual disk, and allow you to power on the VM, or mount the virtual disk. Since you have Player, you unfortunately have no option to create snapshots, so please ensure that you have a current backup!
Depending on the how the guest OS files are spread across the virtual disk files, you may be able to copy/backup some of them natively, or by using some 3rd party file recovery utility.
Another - maybe even better option - is to try and open "MITM tester-0.vmdk" using e.g. 7zip, which is able to handle virtual disks as disk images.
Thank you very much, André.
The good news is that the VM is back up and running. Well done!
The bad news is that some essential data has been lost. Where once was a directory is now a 'broken link' file of 11 bytes.
Ironically, it seems the more recent data is lost while some older stuff is still there.
Anyway, thanks again.