"Disk.vmdk has one or more internal errors that cannot be fixed" - Yes, another one...

[mattdaddym]

Hi,

I took a look around the forum and it seems this error is relatively popular, lol.

I am running Mac OS Sierra and VM Fusion 10.0.1. The VM OS is Windows 7. This error occurred after a system hang that forced me to perform a "hard" reboot. I usually have some kind of snapshot or backup, but that is not the case this time (dumb, I know...but I did make a backup before attempting to troubleshoot). I tried the vdiskmanager repair with no luck.

I'm attaching the log files in case someone can take a look. Thank you!

[mattdaddym]

I think I've found the relevant lines in the log. There are four files where there are "4096 excess bytes at the end of the file." I was going to attempt to trim the files but the files turned out to be 4096 bytes each.  I tried deleting them and a few other manipulations without luck.

2017-10-23T18:17:26.551-05:00| vmx| I125: DISKLIB-LIB   : Failed to open '/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk.vmdk' with flags 0xa The specified virtual disk needs repair (14).

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s052.vmdk] 4096 excess bytes at end of file

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s052.vmdk] Invalid rgdOffset 1

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s052.vmdk] Invalid gdOffset 1605

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s053.vmdk] 4096 excess bytes at end of file

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s053.vmdk] Invalid rgdOffset 1

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s053.vmdk] Invalid gdOffset 1605

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s054.vmdk] 4096 excess bytes at end of file

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s054.vmdk] Invalid rgdOffset 1

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s054.vmdk] Invalid gdOffset 1605

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s055.vmdk] 4096 excess bytes at end of file

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s055.vmdk] Invalid rgdOffset 1

2017-10-23T18:17:27.414-05:00| vmx| I125: DISKLIB-SPARSECHK: [/Users/matt.mercer/Documents/Virtual Machines.localized/OPT003067-VM.vmwarevm/Virtual Disk-s055.vmdk] Invalid gdOffset 1605

2017-10-23T18:17:27.415-05:00| vmx| I125: This is bug 1683.

[a_p_]

Welcome to the Community,

are you familiar with extracting binary data from  files (using e.g. the dd command)?

If so, please attach the VM's descriptor .vmdk file ("Virtual Disk.vmdk"), so that I can figure out the metadata size for the corrupt files. I will then let you know what exactly I need to be able to check the metadata for issues, and to see whether I can help.

André

[a_p_]

Just saw your second post. So as the first step, please provide a complete list of files including sizes.

André

[mattdaddym]

HI,

I've attached info on the files in the directory and the .vmdk.

I'm not an expert with dd, but should be fine with guidance. Thanks!

[a_p_]

According to the files, the virtual disk has been expanded several times, and the last expansion was ~50GB. This last expansion is what's supposed to be backed by the 4 corrupt .vmdk files (s052 through s055). Since the user data in these files is gone anyway, I'd suggest a rather unusual way to try and fix this issue. Please make sure that the backup you have contains all the files (which is not necessarily the case with using Time Machine).

Please follow these steps:

• make note of the virtual disk's currently configured size
• close VMware Fusion to ensure that the VM's files are not in use, or cached
• delete Disk-s052.vmdk through Disk-s055.vmdk from the disk
• delete the lines for these 4 files in the descriptor .vmdk file
• open VMware Fusion, and increase the now shown virtual disk's size to what it was before

The last step will create additional .vmdk files (with the names of the previously deleted files), and ensures that the guest OS will see the same disk size as before. With the loss of the last 4 files, you will - besides the missing/lost data - most likely experience some file system corruption in the guest OS. Make sure that you backup important data from within the guest OS, and then run a disk check utility like chkdsk for Windows.

What I'm unsure at this time is the error regarding "s001", but if this causes issues we'll take a closer look at this in a next step.

André

[mattdaddym]

Hi,

I expanded from 350GB to 400GB the day before or day of corruption. I had to delete my snapshots to do this. I think it also went through some sort of clean up process. At first, everything was fine. Shortly after that my computer hung, forced a hard shut down and here we are.

I followed your instructions and on the last step when attempting to expand from 350 to 400GB again, Fusion stated the VM needed repair. I decided to try and start it at 350GB and it booted (I'm assuming the auto attempt at repair kicked in and was successful). I went ahead and expanded to 400GB after the successful boot and shut down. On the next boot, I was presented with the "checking file system on C:". That completed and everything seems to be working now.

Thank you!