One more time, hopefully with the vmware.log file.

This is on Mac OS X Server 10.5 (Leopard Server).
All latest patches applied from Apple Software Update.

Thanks!

-Brian

Thanks for doing a quick test. It may just be me, it sounds like.

I will re-install Fusion 1.1.1 and see if that helps.

-Brian

What type of Mac is this? Anything unusual about it? Copy/paste in vmware.log?

Which vmdk file was Fusion complaining of being missing when you tried to start the VM?

I dug into this a bit more today.

Looks like something bad has happened to the VMDK files for THREE of my Virtual Machines (the ones with large disks) on this system, but the other TWO VM's that I have run just fine (the ones with small disks, as it turns out).

Here's a snippet of the log file for my straight-up Ubuntu VM:

Mar 24 08:39:53.381: vmfusion| DISKLIB-DSCPTR: Failed to parse embedded descriptor file in normal mode: Wrong line format.
Mar 24 08:39:53.382: vmfusion| DISKLIB-LINK : "/Users/brianberliner/Documents/Virtual Machines/Ubuntu 6.06/Ubuntu.vmdk" : failed to open (The file specified is not a virtual disk).
Mar 24 08:39:53.382: vmfusion| DISKLIB-CHAIN : "/Users/brianberliner/Documents/Virtual Machines/Ubuntu 6.06/Ubuntu.vmdk" : failed to open (The file specified is not a virtual disk).
Mar 24 08:39:53.382: vmfusion| DISKLIB-LIB : Failed to open '/Users/brianberliner/Documents/Virtual Machines/Ubuntu 6.06/Ubuntu.vmdk' with flags 0x15 (The file specified is not a virtual disk).
Mar 24 08:39:53.382: vmfusion| DISKLIB-LIB : Failed to enum '/Users/brianberliner/Documents/Virtual Machines/Ubuntu 6.06/Ubuntu.vmdk' : 16
Mar 24 08:39:53.382: vmfusion| SNAPSHOT: Unable to find all files for 'Ubuntu.vmdk'
Mar 24 08:39:53.382: vmfusion| SNAPSHOT: SnapshotConfigInfoExpandDisks: Error 7
Mar 24 08:39:53.382: vmfusion| Missing virtual disk Ubuntu.vmdk of type disk
Mar 24 08:39:53.382: vmfusion| Missing VM file: Ubuntu.vmdk

The files are there, but Fusion thinks that the VMDK files are corrupted in some way.

As I mentioned earlier, I had briefly installed VirtualBox, but I don't get why the three large disk files are corrupted, yet the small ones appear to be fine.

Any help with the above errors on recovering my VM's?

Thanks!

-Brian

Hi aetm,

Problem resolved (at least for the 1 VM that I use daily)!

It was, indeed, trashing of the VMDK file done by VirtualBox.

Unfortunately, the error codes and messages out of VMware Fusion did not really give me much guidance in figuring out where the problem might be, so I had to slog through it and try a bunch of things.

Here's the very complex steps that I took to recover the VMDK file, after trying numerous things and referring to the VirtualBox source code for hints.

Starting at byte offset 512 in my VMDK file, you will find a "Disk DescriptorFile" and a "The Disk Data Base" section of text that appears to be padded by NULL characters.

In the corrupted VMDK that was mucked with by VirtualBox, mine looked like the following:

1. Disk DescriptorFile

version=1
CID=4c06b51e
parentCID=f6d5af3d
createType="monolithicSparse"
parentFileNameHint="AmyOffice.vmdk"

1. Extent description

RW 41963828 SPARSE "AmyOffice-000001.vmdk"

1. The Disk Data Base

#DDB

ddb.toolsVersion = "7362"
ddb.virtualHWVersion = "6"
ddb.uuid.image="309b24ab-4acf-4b11-cbbe-f6935882d848"
ddb.uuid.modification="12ff42d5-f691-4ba3-7abb-6686efa6d59f"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.geometry.cylinders"0"
ddb.geometry.heads"16"
ddb.geometry.sectors"63"
ddb.geometry.cylinders="0"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"

And, it was padded by NULL characters. I extracted it from the VMDK using "dd":

1. dd if=AmyOffice-000001.vmdk bs=512 skip=1 count=2 > out

I didn't like the look of the entries: Note that there is not an equals sign between the cyclinders/heads/sectors section at the bottom and the values.
That did not sit well with me at all. Nor did I like the value of the cylinders was 0 and the heads/sectors did not match the binary values in the firs data structure after the MAGIC KMDV in the VMDK file.
Badness.

Comparing this text header info with a very old backup of my VMDK file, it appeared that I could drastically simplify this section.

So, I did.

I edited the "out" file, and made the following changes:

• Changed the CID to 613506eb
• Deleted everything after this line (kept it): ddb.toolsVersion = "7362"
• Extended the NULL padding at the end to get the file back up to 1024 bytes exactly.

Then, I patched the VMDK with the following command:

1. dd conv=notrunc if=out of=AmyOffice-000001.vmdk bs=512 oseek=1 count=2

Don't forget the "conv=notrunc", or your VMDK file will be truncated (which I did, and had to copy over from backup again. Ugh).

And, guess what, the Virtual Machine booted with absolutely no problem.

I immediately grabbed the data that I wanted out of the VM, then created a fresh Snapshot.

All is well with my silly Windows VM now. I promise to implement a bettwer Windows VM backup process (it would be great if I could just let Time Machine handle this, but the VM is 30GB)...

Anyway, hope this helps someone else that gets bit by VirtualBox, as I did.

-Brian

Attempting to change the Subject line to reflect the actual issue (VirtualBox)