Disk has one or more internal errors that cannot be fixed

[Isaac Xolo]

Hello, I started using VMware Fusion just last month and never had any problems, last night while I was using it I got this alert and exited.

"The disk '/Volumes/KINGSTON/Windows 11 64-bit Arm.vmwarevm/Virtual Disk.vmdk' has one or more internal errors that cannot be fixed."

Restore from a backup copy of this disk.
The specified virtual disk needs repair.

Cannot open the disk '/Volumes/KINGSTON/Windows 11 64-bit Arm.vmwarevm/Virtual Disk.vmdk' or one of the snapshot disks it depends on.

Module 'Disk' power on failed.

Failed to start the virtual machine.

I haven't been able to get it to work and was wondering if anyone could help me. 

-------------------------------------------

Attachment(s)

vmware.log   127 KB 1 version

filelist.txt   6 KB 1 version

[Technogeezer]

That virtual disk is indeed having some issues. 

First things first: Make a backup of this VM's bundle in its current state before attempting anything further.

I'd do a data collection from that VM using the script and information found in this post: https://community.broadcom.com/vmware-cloud-foundation/viewdocument/get-vmdkmetadatash-script-to-col?CommunityKey=0c3a2021-5113-4ad1-af9e-018f5da40bc0&tab=librarydocuments 

Attach the file from the data collection to a reply to this thread and we'll see if we can get our resident VMDK corruption expert to weigh in on if this is fixable. Note that any repair of the VM could result in data loss -- if it's successful at all. (That's why the recommendation to restore from backup). 

Random thoughts:

I notice that the volume name that this VM is stored on is called "KINGSTON". It wouldn't happen to be on a USB flash/thumb drive would it? 

What is the file system format on that volume? APFS, HFS+, FAT, or ExFAT? APFS or HFS+ are fine, but I don't recommend running a VM on FAT or ExFAT. 

Is that disk volume running out of space?

The log you posted indicated that you are running macOS Sequoia 15.1.1 That's over a year behind in updates to Sequoia and is missing a lot of bug and security fixes.

------------------------------
Paul Rockwell (technogeezer)
vExpert 2026 (3x)
------------------------------

[Isaac Xolo]

The VM is stored on an external SSD and the filesystem format of the volume is ExFAT but the disk is not running out of space, it has approximately 600 free GB. I just updated my OS as well

This is the metadata ZIP file. Thanks for all the help

-------------------------------------------

Attachment(s)

Vmdk-Metadata-20260305-083210.zip   14.15 MB 1 version

[Technogeezer]

I'd strongly recommend not to run a Fusion virtual machine on an ExFAT file system. ExFAT is OK for transportation of a VM to other systems, but not for running it.

We've had reports of Fusion crashing and other unexpected behavior when running a VM stored on ExFAT. i've also found through personal testing that there are some file system operations that don't work on ExFAT file systems. It would not surprise me if you've encountered a problem with running on ExFAT and that's what corrupted your virtual machine.  (Posting all the vmware*.log files in the VM bundle may give us a clue if something may have happened before this repair attempt failed). 

I'd recommend backing up everything on that external SSD, reformat it as APFS and restoring the contents before attempting further repairs.

------------------------------
Paul Rockwell (technogeezer)
vExpert 2026 (3x)
------------------------------

[Technogeezer]

@a_p_ can you take a look at this and see what you think?

------------------------------
Paul Rockwell (technogeezer)
vExpert 2026 (3x)
------------------------------

[a_p_]

The file contains a duplicate grain table entry.
For the duplicate entry (a 64kB block) I had to make an assumption, and decided to remove the first occurrence.

00000048: 01 -> 00
000253AC: 80 -> 00
000253AD: 6C -> 00
000253AE: DE -> 00
000253AF: 01 -> 00
001B31AC: 80 -> 00
001B31AD: 6C -> 00
001B31AE: DE -> 00
001B31AF: 01 -> 00

To fix the metadata, either use a hex editor, or run the following commands:

dd if=/dev/zero of="Virtual Disk-s044.vmdk" bs=1 seek=72 count=1 conv=notrunc

dd if=/dev/zero of="Virtual Disk-s044.vmdk" bs=1 seek=152492  count=4 conv=notrunc
dd if=/dev/zero of="Virtual Disk-s044.vmdk" bs=1 seek=1782188 count=4 conv=notrunc

Line 1 will reset the "uncleanShutdown" flag
Lines 2-3 will reset the duplicate pointer within the grain table

I strongly recommend that you backup the .vmdk file before making the modifications. There's also a chance of some file system corruption within the guest OS.

André

-------------------------------------------