The file specified is not a virtual disk error when opening a snapshot (original disk descriptor is missing)

[Coolak777]

Hello everyone. I recently accidentally removed a very important snapshot. Then I was able to restore all its sparse .vmdk files (s001 through s011), but unfortunately not the descriptor vmdk file and not the old vmsd file. The snapshot was in suspended state. I attempted to manually add it to the vmsd file and to recreate the descriptor vmdk file myself, but always says "The file specified is not a virtual disk" when attempting to fire up the snapshot.

Kali-Linux-2016.2-vm-amd64-000005.vmdk is attached as an example of a working snapshot's descriptor file based on which I recreated Kali-Linux-2016.2-vm-amd64-000004.vmdk. Also I attached the descriptor file of the main virtual disc (Kali-Linux-2016.2-vm-amd64.vmdk) and the .vmx file of the virtual machine (Kali-Linux-2016.2-vm-amd64.vmx). Thank you in advance for any help.

[Coolak777]

P.S. forgot to add that I also recovered .vmem and .vmsn files. Basically I recovered everything but the original descriptor.

[a_p_]

Welcome to the Community,

The descriptor file seems to be ok, although I'd suggest you remove the "ddb.longContentID" entry (even though you added the "#") from it to avoid confusion.

Anyway, since the descriptor seems to be ok, you may need to check the sparse files for errors. A first quick check would be to see whether these files start with "KDMV" (reverse of "VMDK"). Often issues like yours is related to file corruption in recovered .vmdk files.

Some time ago I posted an XLS file with a macro, which checks .vmdk files (see Re: Corrupt redo log freezing VM​). Maybe this helps.

André

[Coolak777]

Thank you for the reply. I removed the "ddb.longContentID" long ago, just decided to keep it in the uploaded file.
What file size should I specify in the macros? The one it calculates automatically or the real size of the virtual machine's disk? With the automatically calculated size it says "Invalid MagicNumber" for all files. Does it mean they are corrupted?

[a_p_]

The prepopulated size is the .vmdk file's size in bytes, and usually doesn't need to be changed.

If the Magic Number (the first 4 bytes) is iinvalid, then it's at least the file's metadata which is corrupt. At this point I'd usually ask to send me the first ~640kB of the .vmdk files, which is the metadata part. However, with overwritten files this part of the files could contain user data, so it may not be a good idea to post it on a public forum.

What might be an option is to use a hex editor and post a screenshot of the first few hunded bytes (for one of the .vmdk files). This might already be sufficient to see whether there's a chance to repair the files.

André

[Coolak777]

Actually they are all filled with nulls for a solid part starting from the beginning, so seems like the snapshot is unrecoverable. But at least I will keep in mind what to do in the future in such cases, and it's good to know that I was able to properly recreate the descriptor file. Thank you for your help.

[Coolak777]

Still I'd like to attach some portion of the first sparse file. Maybe there's still some chance despite the nulls in the beginning?

[Coolak777]

I just found out that no snapshot loads with my edited .vmsd file. But as soon as I remove the lines belonging to my restored snapshot, all other snapshots load. Can you please tell me what's wrong with my .vmsd?

Attached is the more correct version (please ignore the vmsd file from the first post). But it still gives the same error if I leave any lines belonging to that snapshot.

[a_p_]

If all the files look this way, then yes, this may nothing that can be easily recovered. I assume that it's not only the metadata which has been corrupted but also parts of the user data.

Sorry that I can't help you with this.

André

[a_p_]

Can you provide some screen shots how the snapshot tree is supposed to look, and provide details about the files in the VM's folder (i.e. a complete list of files like the output of dir *.*, or ls -lisa)

André

[Coolak777]

Please see attached.

[a_p_]

Sorry, but I'm afraid that I can't really help you with this.

It looks like there's more that's missing, e.g. snapshot "...-000001.vmdk" as well as a .vmsn file. I tried to reproduce the state without success.

André