VMware Communities
fusion827
Contributor
Contributor
Jump to solution

vmware The disk vmdk has one or more internal errors that cannot be fixed.

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.

1 Solution

Accepted Solutions
a_p_
Leadership
Leadership
Jump to solution

Unless the user data itself is corrupted, there might be a chance to fix the .vmdk.

What I found are two issue:

  1. There's a mismatch in one of the grain table entries, and its redundant entry. Since the original entry points to an address which exceeds the expected file size, I think this is the one we need to fix. The grain table entry at offset 11,196,004 (decimal) currently reads "00 2C 37 06", but should be "00 1F 37 06".
  2. According to the metadata, the expected file size is 53,390,868,480 bytes, so the file size needs to be reduced.

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é

View solution in original post

8 Replies
a_p_
Leadership
Leadership
Jump to solution

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é

fusion827
Contributor
Contributor
Jump to solution

file attached.

thank you

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

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é

Reply
0 Kudos
fusion827
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

... 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é

Reply
0 Kudos
fusion827
Contributor
Contributor
Jump to solution

attached meta file zip

Jim

Reply
0 Kudos
a_p_
Leadership
Leadership
Jump to solution

Unless the user data itself is corrupted, there might be a chance to fix the .vmdk.

What I found are two issue:

  1. There's a mismatch in one of the grain table entries, and its redundant entry. Since the original entry points to an address which exceeds the expected file size, I think this is the one we need to fix. The grain table entry at offset 11,196,004 (decimal) currently reads "00 2C 37 06", but should be "00 1F 37 06".
  2. According to the metadata, the expected file size is 53,390,868,480 bytes, so the file size needs to be reduced.

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é

fusion827
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos