fusion vm will not start.
computer crashed during disk space recovery
problem report is 72mb, too big to attach here.
Need some help to see if vm can be fixed with a tool or manual changes.
Unless the user data itself is corrupted, there might be a chance to fix the .vmdk.
What I found are two issue:
Issue one can easily be fixed using a hex editor. However, I'm not 100% sure how to cut the .vmdk file into the expected size on a MAC.
You may try to clone the required bytes to a new file using dd again (sample command below), which however will require sufficient free disk space! Also note that in order to use the cloned .vmdk file, it needs to be renamed to the original file's name!
dd if=original.vmdk of=clone.vmdk bs=1024 count=52139520
--> rename original.vmdk to original.vmdk.bak
--> rename cloned.vmdk to original.vmdk
I'd actually do the cloning first, and then use a hex editor to edit the cloned .vmdk file. This way the original file doesn't get modified, in case it's still needed.
André
What we can try is to run an check for the .vmdk files to see what's corrupt.
In order for this please extract the VM's folder from the support bundle which you created. This folder should contain all the VM's files - except for the data .vmdk files - as well as a complete file list which shows the files' exact sizes. Please compress/zip this folder and attach it to a reply post. Depending on this data I will ask you later to extract the metadata part from the .vmdk data files.
André
It seems that the .vmdk file is either larger than expected, or that the grain table has been (partly) damaged.
What you may want to try is to run a repair for the .vmdk file (see The specified virtual disk needs repair), but make sure you do this on a copy of the .vmdk file (or with a current backup in place).
If this doesn't work, I'd need the .vmdk file's exact size (in bytes), and the provisioned size (i.e. the disk size that was entered in the VM's settings).
Maybe continuum has another idea!?
André
I ran the repair but it didn't do anything, it returned file corrupt message.
Size of vm was 120gb, I had a lot of recovery size shown on the display in vmware library window, maybe around 60gb.
124,504,244,224 bytes (124.5 GB on disk)
Jim
... I had a lot of recovery size shown on the display in vmware library window, maybe around 60gb
Sorry, but I'm not sure what this means!?
Anyway, not being an expert for MACs, I'd ask you to extract the metadata from the VM's .vmdk file, compress/zip it and attach the .zip archive to a reply post.
The metadata for a 120GB virtual disk is stored in the first 15,794,176 bytes of the file. For Windows/DOS there's nice little tool which can do this, for OSX I think you will have to do this using the dd command line utility. Unless I'm mistaken something like the below command should work (please double-check):
dd if=your-virtual-disk-file.vmdk of=metadata.bin bs=15794176 count=1
The command may require sudo to run.
André
Unless the user data itself is corrupted, there might be a chance to fix the .vmdk.
What I found are two issue:
Issue one can easily be fixed using a hex editor. However, I'm not 100% sure how to cut the .vmdk file into the expected size on a MAC.
You may try to clone the required bytes to a new file using dd again (sample command below), which however will require sufficient free disk space! Also note that in order to use the cloned .vmdk file, it needs to be renamed to the original file's name!
dd if=original.vmdk of=clone.vmdk bs=1024 count=52139520
--> rename original.vmdk to original.vmdk.bak
--> rename cloned.vmdk to original.vmdk
I'd actually do the cloning first, and then use a hex editor to edit the cloned .vmdk file. This way the original file doesn't get modified, in case it's still needed.
André
Changing the 2c to the 1f fixed it perfectly. I used the free mac app Hex Fiend.
Nothing lost and all running as before.
Thank you.
Jim