Error: the file specified is not a virtual disk

[gs1s]

After working flawlessly for months, something went haywire today and my next attempt to access my VM in Fusion was met with "the file specified is not a virtual disk".  I have followed a number of proposed solutions here and on the support page to no avail.

One question I have is does it make sense that my .vmdk file is 1 KB in size and the text when viewed in TextEdit is gibberish (compared to, say, my .vmx file which reads in mostly plain English)?  The last update to my .vmdk was at 12:33 pm today, where many of the other files (including the 21 s###.vmdk files) were updated at 2:52 pm.  Is it possible my .vmdk file is corrupted?  If so, can it be rebuilt if I don't have a backup?

[gs1s]

One possible solution - the hard drive I'm working from was cloned from another drive 2 weeks ago.  A such, the former drive should have a fully functioning copy of Fusion with a working VM on it, just 2 weeks old.  Is it possible to take my old .vmdx file from that drive and replace the possibly corrupted one on the current drive?

I don't have Time Machine backups of my VM file, which in reading here is not a failsafe method of backing up a VM.  I use the VM to run Microsoft Money in Windows 7 and have many years worth of financial records in it.  I swore I was backing up Money to my Mac regularly (outside the VM) and Time Machine backing up that file, so if I ever had to create a new VM it would not be a problem, but that appears to have not been working for quite some time.  Even if the above solution means losing 2 weeks of history, that's better than losing everything.  I wonder if a dated .vmdx file pointed to more current sparse files might work, but admittedly have no idea what information is stored in the various file types.  In case you were wondering, I have no snapshots of the VM - didn't know that feature existed until searching here tonight.

I really appreciate any help anyone can provide.  As you can probably read from my questions, I have no experience with this stuff.  I'm happy to provide any additional information to help diagnose my issue.  Thanks.

[changhai]

gs1s,

1. VMX file

checked VMX file, it is quite strange:

• normally, the virtual disk name should Virtual Disk.vmdk, while it is Window XP Pro.vmdk.
• this guest type is Window 7. it use one Window XP Pro.vmdk. is the filename correct ?

...

scsi0:0.fileName = "Windows XP Pro.vmdk"

...

displayName = "Windows 7"

guestOS = "windows7"

2. VMDK file

using text edit to open the Window XP Pro.vmdk, it is not a perfect VMDK description file obviously.  and using the command "file ./Window XP Pro.vmdk" it is one "data" type file; normally it should be one ASCII English text file (split to multiple files) or VMware4 disk image file (non-split).

I have one suggestion to create a new same size of virtual disk and rename the VMDK description file to replace bad one: Window XP Pro.vmdk and power on the VM to see what happens after you backup the original Window XP Pro.vmdk file.

Best Regards,

changhai

[WoodyZ · Accepted solution]

If you do not have a proper copy of the "Windows XP Pro.vmdk" file to replace the corrupt one with then use the attached one that was created from information in the supplied vmware.log file from the .tgz support bundle.

The attached "Windows_XP_Pro.vmdk.zip" file contains a new "Windows XP Pro.vmdk" file to replace the corrupted one.

[gs1s]

Thank you, WoodyZ. A hundred times, thank you.

A simple swap of the file you provided for the corrupt one, tell Fusion I copied the VM and everything now seems to work fine.

A proper backup of the Money file in question has been made to avoid this in the future, and I'll be following your VM backup best practices so I don't have to trouble you again.

Thanks again.

[WoodyZ]

changhai wrote:

1. VMX file

checked VMX file, it is quite strange:

• normally, the virtual disk name should Virtual Disk.vmdk, while it is Window XP Pro.vmdk.
• this guest type is Window 7. it use one Window XP Pro.vmdk. is the filename correct ?

...

scsi0:0.fileName = "Windows XP Pro.vmdk"

...

displayName = "Windows 7"

guestOS = "windows7"

@changhai The plausible explanation for this is the original VM was as reflected by the name of the virtual hard disk a Windows XP Pro VM that was then at some point upgraded to Windows 7.

2. VMDK file

using text edit to open the Window XP Pro.vmdk, it is not a perfect VMDK description file obviously.  and using the command "file ./Window XP Pro.vmdk" it is one "data" type file; normally it should be one ASCII English text file (split to multiple files) or VMware4 disk image file (non-split).

The command as you've written "file ./Window XP Pro.vmdk" (sic) would fail as it is neither properly quoted or escaped as shown below:

file ./Window\ XP\ Pro.vmdk

file "./Window XP Pro.vmdk"

I have one suggestion to create a new same size of virtual disk and rename the VMDK description file to replace bad one: Window XP Pro.vmdk and power on the VM to see what happens after you backup the original Window XP Pro.vmdk file.

What you propose here, as proposed, will fail because you cannot just change the name of the Disk DescriptorFile from "Virtual Disk.vmdk" to "Windows XP Pro.vmdk" because the contents of the Disk DescriptorFile would still have "Virtual Disk-s###.vmdk"" for all of the Extents and would need to be edited as well, which you didn't mention.

In case such as this, especially when a vmware.log file is available, I find it's much easier to use vmware-vdiskmanager to create a new virtual hard disk based on the facts in the vmware.log file and then provide the file to the User, as I did.

[gs1s]

WoodyZ, you're correct in that this VM was originally an XP Pro installation that was subsequently upgraded to Win 7.  The VM runs Win 7, but I was also a bit puzzled when all of the .vmdk files still said XP Pro.

[WoodyZ]

gs1s wrote: The VM runs Win 7, but I was also a bit puzzled when all of the .vmdk files still said XP Pro.

Under the circumstances that is normal and expected since what you did, aside from some necessary edits to the .vmx configuration file, you installed Windows 7 into an existing Windows XP VM.  Look at it this way...  Say this was a physical machine with a Western Digital Hard Drive and Windows XP installed and you then upgraded to Windows 7, it's still a Western Digital Hard Drive.  VMware at some point changed the default naming convention for the virtual hard disk when creating a VM.  It used to name the virtual hard disk the name of the VM and now in VMware Fusion 5 unless the User intervenes it names it "Virtual Disk.vmdk".  So you most likely created that VM before VMware Fusion 5 and it was at the time appropriately named for the OS first installed.  Upon upgrading the OS installed it did but it would not change the existing name of the virtual hard disk!

[gs1s]

Also helpful, and you're correct that this VM was created in Fusion 4 and I later upgraded to Fusion 5.