Resuming Paused VM results in "The file specified is not a virtual disk"

[bingB]

Resuming Paused VM results in "The file specified is not a virtual disk".  I'm running workstation9 and my vm has been stuck this way since October 2015.  I tried a few things initially but have put the entire host on ice until now(I really need help salvaging this vm and data!!)

As stated, I believe the vm worked fine until October 2015.  Up until then, I had frequently paused and resumed the vm as a matter of practice.  One day I got this error and have not been able to get back into the vm since then.  I have been careful not to change the files through my vain troubleshooting attempts.

I've attached a complete list of the files in the vm's folder, along with the two log files contained in the folder

Any expertise/help/advice would be greatly appreciated

[rcporto]

Looks like your VMDK header/descriptor is missing/corrupt, for possible solution, check the following KB article: VMware KB: Recreating a corrupt or missing VMDK header/descriptor on hosted products

[bingB]

ok, I'm trying the article but the article takes me down two paths (depending on whether my vm is using persistent disks or not).  Because the VM is paused(and will not let me change it to the shut down state, I cannot go into the advanced disk settings to determine whether the disk is set to persistent or not)

Edit:  I just tried to follow the article, which says I will need to " use vmware-vdiskmanager utility to create a new disk of the same type and size of the -flat.vmdk file "

I do not see amy -flat.vmdk file in my existing vm directory, so hwo would I create a new file of the same size?  I'm not sure how to find the size of my -flat.vmdk file.

[bingB]

I have one vmdk file in the vm's directory, and it is named RemoteXP.vmdk .  Its named after the vm itself, and its size is 0 KB's

[wila]

Hi,

Sorry for the bad news, but you cannot recover data from a virtual disk that is 0 bytes in size, if your list of files attachement is correct then that VM is completely gone.

The last boot according to your log from October 30, pointed to a disk file:

E:\Users\BB\Documents\Virtual Machines\RemoteXP\RemoteXP.vmdk

If that's the one that is 0 bytes in size then you better start looking for a backup, which I hope you have.

--

Wil

[continuum]

Run a checkdisk with all options like
chdsk /f /x /r against the drive.
If you are lucky that may help.
If not - only chance is to use tools like GetDataBack or UFSexplorer.

[bingB]

Thanks for the suggestions guys.  I cannot afford to give up on this vm just yet, so here is what I've tried.

I've run numerous chkdsk scans (/f/x/r) and filesystem repairs on the hosts 2TB hard disk.  Errors were found during the process and corrected.

There were no recovered vmdk files however.  I'm still stuck with my single 0kb vmdk file.  One thing to note is that this VM had been set up to use a single vmdk file (rather than numerous vmdk files as are commonplace with vm's today).

-I believe I'd allocated at least 100 gb of disk space to this vm.

- The vm's directory currently has a 4GB vmem file and a 132mb vss file  (the vm has been stuck in a paused/suspended state since October 2015).

I ran a Data Recovery tool in deep scan mode, and did not discover any recent version of this vm's vmdk file.  The tool was able to find everything under the sun EXCEPT this missing vmdk file.  I never deleted the vmdk file, so its bizarre that it would just disappear -or- turn into a 0kb file like that.

**WHat I did find**  I did find a 2013 version of a vmdk file for this virtual machine during the deep scan but its only 17GB.  If I attempted to use this version would it restore my virtual machine's contents to what it was in 2013?

Thanks for the help

[continuum]

RemoteXP.vmdk is / was a monolithicSparse.vmdk - which following the logs was in a state so that WS did not accept it as a healthy vmdk.
With monolithicSparse this also means the embedded header of the file is damaged.
This again also means that all signature-based recovery-tools will not detect this as a valid vmdk of type "monolithicSparse"
So your situation is as follows: what ever your recovery attempts may have produced as a result : it is very likely meaning less.
If this is really valuable data then I hope you used a LiveCD for your recovery attempts and did not run them from the affected volume !!!
Anyway - let me have a look - I maybe able to locate the file in your recovery results by using other serach criteria.
To get an idea about the reliabilty of your scans - please specify the tools you used.
Before you give up - call me - see signature

Ulli