I've just run into an issue that I have not previously encountered in Workstation (been using it since v8).
I have a Windows 8.1 host system, Workstation 14.1.1 and a Windows 10 guest that is cloned (linked) to a snapshot in the "parent" VM.
The parent VM, in Snapshot manager, shows the snapshot, with the padlock icon and if I go to delete it, it correctly tells me that deleting this snapshot will break my cloned VM (so of course I don't delete it).
Yet, when I go to start the cloned VM, it tells me it cannot find the dependent snapshot *.vmdk file. I can browse for it, and it's definitely there, but it refuses to recognize the file (even though the name is correct and identical).
The snapshot was created (I am pretty sure) in Workstation 12.5.7, but I don't see why that would make a difference?The cloned VM was created in Workstation 14.1.1..
Looking like my clone is a write off? How can a cloned VM reject a linked *.vmdk that hasn't been modified since well before the linked clone was created from it?
To get an overview, please provide a complete list of files in the VMs' folders, i.e. the output of dir *.* /one., along with the VM's configuration (.vmx), and snapshot (.vmsd) files.
If you are using a split virtual disk format with the .vmdk metadata (a few hundred bytes) in separate files, then compress/zip all those header .vmdk files, and attach the .zip archive to a reply post. In case you are using monolithic virtual disks (i.e. one large .vmdk file), download dsfok.zip from http://faq.sanbarrow.com/index.php?action=artikel&cat=47&id=111&artlang=en, extract the executables, run the below mentioned command in the VM's folder, then compress/zip all the "xxx-....bin" files and attach them to a reply post too.
for %i in (*.vmdk) do @dsfo.exe "%i" 0 1536 "xxx-%~ni.bin"
Note: The command will extract only metadata (i.e. no user data) from the .vmdk files.
Remeber to provide the above requested information for both, the base VM's directory as well as the clone's directory
I very much appreciate the response. Given that I hadn't put a lot of effort into the cloned VM, I decided to delete it and start again. After deleting it (through Workstation) I notice that the snapshot in the parent still thinks it has a dependent linked clone, so I guess somewhere along the way the link between the two got messed up.
I'm going to re-create the linked VM and if the issue occurs again, I will follow the steps that you have detailed (again, thanks).
In the meantime it seems to take 15+ minutes to update VMware tools (which seems slightly tardy), so it looks like I have other problems to try to figure out in advance of any potential recurrence of this issue.
EDIT: Created a new linked VM. Started it up 15 mins ago (no exaggeration), and it's still not started. Yep, I have bigger problems to solve first.