How to restore missing vmdk file in fusion 5.0.1

[CZR10001]

I am running VMWare Fusion 5.0.1 using Windows 7 on an Macbookpro running OS X 10.6.8

I recently had a crash and now when I try to start Windows using Fusion I get this message: "File not found: Windows 7.vmdk. This file is required to power on this virtual machine.  If this file was moved, please provide its new location.."

The problem is that the file is there and doesn't seem to be corrupted and I have no idea what I need to do to recover the file. I have no back-up files.

As I am new Mac user, if anyone has a step by step solution I would appreciate your help.

Thank You very much

[WoodyZ]

To help figure out what is what, the best way to provide comprehensive diagnostic information is to use the "Collect Support Information" command from the VMware Fusion (menu bar) > Help > Collect Support Information and then attach the .tgz file it created on your Desktop to a reply post.

[abirhasan]

Please have a look this kkkb may help..

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=102741...

abirhasan 

[CZR10001]

Attach is the tgz file requested.

I really do appreciate your help!

[continuum]

/Users/cesarhinojosa/Windows 7.vmwarevm/Windows 7.vmdk should have 51 files named Windows 7-s00*.vmdk.

looks like it only has 21 - if at all ? - if you cant find the missing files you can not fix the VM

[WoodyZ]

Ulli, I saw that too however the "parentFileNameHint" in the "Disk DescriptorFile" for the "Windows 7-000001.vmdk" snapshot is pointing to "/Users/cesarhinojosa/Desktop/Windows 7.vmdk" and there is no other information in the support bundle to verify whether or not it exists, although I'd say it doesn't.  Also there is a discrepancy between what is showing in the vmware.log file and the ls.txt file in the Virtual Machine Package.  The ls.txt shows the Windows 7-s001.vmdk to Windows 7-s051.vmdk in the Package but not the Windows 7.vmdk file and without knowing what is in the parentFileNameHint="/Users/cesarhinojosa/Desktop/Windows 7.vmdk" file it's hard to say what the full story on this issue is.

I actually meant to follow up on this the other day however when I see convoluted info such as this sometimes I just do not have the time to deal with it and why I didn't follow up the other day. (This is one of those cases where I'd rather talk directly to the User and do a TeamViewer session then have to follow up in the thread although I just do not have the time right now for either.)

[CZR10001]

I'm not sure if I'm looking at this correctly, but I opened the windows 7 icon and looked at it's package contents.

I saw the following files:

Windows 7-000001-s001.vmdk  (in ordrer through)  Windows 7-000001-s051.vmdk

Windows 7-000001.vmdk (in order through)  Windows 7-000002-s051.vmdk

Windows 7-000002.vmdk

Windows 7-8fd8e676.vmss

Windows 7-s001.vmdk (in order through ) Windows 7-s051.vmdk

Windows 7.nvram

Windows 7.plistI

Windows 7.vmsd

Windows 7.vmx

Windows 7.vmxf

Windows 7.vmx.lck

I hope this will help find a solution for me.  I again appreaciate all the help I can get WoodyZ and Continuum.

WoodyZ, I understand your busy I will definately wait patiently.  Let me know how and when we can get in toch.

Thank you for your time.

[continuum]

please find and post Windows 7.vmdk - that should be a small textfile
If you do not have it - then this is the problem

[WoodyZ]

I'm assuming you live in the US, if you do and want to send me your phone number via Private Message I'll give you a call.

[continuum]

Windows 7.vmdk should look like this one - so if you dont find the original - use this one

# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=c02208c8
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"

# Extent description
RW 4192256 SPARSE "Windows 7-s001.vmdk"
RW 4192256 SPARSE "Windows 7-s002.vmdk"
RW 4192256 SPARSE "Windows 7-s003.vmdk"
RW 4192256 SPARSE "Windows 7-s004.vmdk"
RW 4192256 SPARSE "Windows 7-s005.vmdk"
RW 4192256 SPARSE "Windows 7-s006.vmdk"
RW 4192256 SPARSE "Windows 7-s007.vmdk"
RW 4192256 SPARSE "Windows 7-s008.vmdk"
RW 4192256 SPARSE "Windows 7-s009.vmdk"
RW 4192256 SPARSE "Windows 7-s010.vmdk"
RW 4192256 SPARSE "Windows 7-s011.vmdk"
RW 4192256 SPARSE "Windows 7-s012.vmdk"
RW 4192256 SPARSE "Windows 7-s013.vmdk"
RW 4192256 SPARSE "Windows 7-s014.vmdk"
RW 4192256 SPARSE "Windows 7-s015.vmdk"
RW 4192256 SPARSE "Windows 7-s016.vmdk"
RW 4192256 SPARSE "Windows 7-s017.vmdk"
RW 4192256 SPARSE "Windows 7-s018.vmdk"
RW 4192256 SPARSE "Windows 7-s019.vmdk"
RW 4192256 SPARSE "Windows 7-s020.vmdk"
RW 4192256 SPARSE "Windows 7-s021.vmdk"
RW 4192256 SPARSE "Windows 7-s022.vmdk"
RW 4192256 SPARSE "Windows 7-s023.vmdk"
RW 4192256 SPARSE "Windows 7-s024.vmdk"
RW 4192256 SPARSE "Windows 7-s025.vmdk"
RW 4192256 SPARSE "Windows 7-s026.vmdk"
RW 4192256 SPARSE "Windows 7-s027.vmdk"
RW 4192256 SPARSE "Windows 7-s028.vmdk"
RW 4192256 SPARSE "Windows 7-s029.vmdk"
RW 4192256 SPARSE "Windows 7-s030.vmdk"
RW 4192256 SPARSE "Windows 7-s031.vmdk"
RW 4192256 SPARSE "Windows 7-s032.vmdk"
RW 4192256 SPARSE "Windows 7-s033.vmdk"
RW 4192256 SPARSE "Windows 7-s034.vmdk"
RW 4192256 SPARSE "Windows 7-s035.vmdk"
RW 4192256 SPARSE "Windows 7-s036.vmdk"
RW 4192256 SPARSE "Windows 7-s037.vmdk"
RW 4192256 SPARSE "Windows 7-s038.vmdk"
RW 4192256 SPARSE "Windows 7-s039.vmdk"
RW 4192256 SPARSE "Windows 7-s040.vmdk"
RW 4192256 SPARSE "Windows 7-s041.vmdk"
RW 4192256 SPARSE "Windows 7-s042.vmdk"
RW 4192256 SPARSE "Windows 7-s043.vmdk"
RW 4192256 SPARSE "Windows 7-s044.vmdk"
RW 4192256 SPARSE "Windows 7-s045.vmdk"
RW 4192256 SPARSE "Windows 7-s046.vmdk"
RW 4192256 SPARSE "Windows 7-s047.vmdk"
RW 4192256 SPARSE "Windows 7-s048.vmdk"
RW 4192256 SPARSE "Windows 7-s049.vmdk"
RW 4192256 SPARSE "Windows 7-s050.vmdk"
RW 102400 SPARSE "Windows 7-s051.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "7"
ddb.geometry.cylinders = "13054"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

[WoodyZ]

Ulli, did you see my reply, Re: How to restore missing vmdk file in fusion 5.0.1?

The "parentFileNameHint" in the "Disk DescriptorFile" for the "Windows  7-000001.vmdk" snapshot is pointing to  "/Users/cesarhinojosa/Desktop/Windows 7.vmdk" so isn't that going to still be a problem even if he creates a new Windows  7.vmdk and places it in the package with the other snapshots.  It doesn't make sense that the "Disk DescriptorFile" for the "Windows  7.vmdk" be on the Desktop while the binary extents are in the Package and if that be the case then the "Disk DescriptorFile" for the "Windows  7.vmdk" on the Desktop would have to have the path to the extents included unless the extents are on the Desktop and replacing just the "Disk DescriptorFile" for the "Windows  7.vmdk" on the Desktop would work.  Otherwise wouldn't the "parentFileNameHint" in the "Disk DescriptorFile" for the "Windows  7-000001.vmdk" need to be edited for the base extents that already exist in the same package?

[continuum]

Yep - I think the parentfilenamehint in *-000001.vmdk needs to be corrected.

But in this case I would not even pretend that I understand the history of the VM 😉

in one log the Windows 7.vmdk looked like it uses 60 Gb - in the last one only 40 Gb ??? - go figure ?

My theory is that someone edited Windows 7.vmdk manually - though that would be unexpected on a Mac host 😉

I am also surprised about this 2 lines:

ddb.consolidateDestFileName = "/Users/cesarhinojosa/Documents/Virtual Machines.localized/Windows 7.vmwarevm/Windows 7.vmdk"
ddb.resumeConsolidateSector = "6001920"

I have never seen this 2 parameters before - I would guess the Fusion detected an error in sector 6001920 and had planed to fix it on next launch ???
Have you seen this 2 lines before ?

[WoodyZ]

Ulli, I'm talking on the phone with Cesar and will do a TeamViewer session in about 30 minutes after the VM backup is finished.  Will post back with results and go from there.  Thanks, Woody

[continuum]

Good - please ask whether anything in the recent history of the VM has happened - other than sabotage - that would eventually explain  the size change of the base vmdk.
I would also like to know if any attempt was made to delete snapshot 000001 some time ago

Ulli

[WoodyZ]

Sorry, I didn't see this before we finished on the phone however what I can tell you is Cesar was unsure how all of this came to past however here it what happened.  After he got the error he talked directly with VMware and basically was sold the upgrade to VMware Fusion 5 as what was needed to fix his issue.  You and I both know that's BS and also wouldn't upgrade in the middle of the issue unless it was a case like where the current version is incompatible the the OS because of a Host OS upgrade but that wasn't the case here!

Anyway, what I did after the current VM was backed up is use your info to create the new base disk .vmdk and edited the 000001.vmdk to remove the erroneous pointer to the parent disk.  The VM had originally been suspended but while the .vmss file was present the .vmem was not so let VMware Fusion discard that state.  Also as you know there were two snapshots however the .vmsd file was zero length.  So instead of manually creating one from info in the vmware.log file I just suggested he take a snapshot and then delete it and that should clear up the orphaned snapshots.  Also turned off Auto-Protect and discussed the pros/cons of using it.  If I had to take a wild guess at what caused this whole mess I'd say Auto-Protect.

Cesar is going to do a user data backup and then resolve the snapshots and startup/shutdown the VM to make sure all is okay, check the package to make sure the orphaned snapshots are gone, properly backup the now known good working Virtual Machine and then go from there.

[CZR10001]

Hello WoodyZ you assisted me in the past with a team view session and I truely appreciated your help.   I was wondering if you would be able to help me once again.  I partitioned my MacBook Pro with fushion.  I’m running out of hard drive space and  would like to lower the partitioned disk space. Can you help?