I went to defragment one of my virtual machines that was performing poorly. When I went to defrag, I received the error “The specific virtual disk needs repair”

Reason: the specific virtual disk needs repair.

The above happened to me on VMWare Workstation 15.

A way around this is as follows:

  • Open command prompt
  • In the command prompt go to the location of where vmware is installed, in my case: “C:\Program Files (x86)\VMware\VMware Workstation”
  • Make a note of the vmdk file you need to deal with (the error will show you the path and filename of the file you need to deal with.
  • On the command prompt run: vmware-vdiskmanager.exe -R “path of the vmdk file”
  • Hit enter
  • You should get a reply that says: “The virtual disk ‘path of file’ , was corrupted and has been successfully repaired.”
  • Below is what it looks like on my end:

C:\Program Files (x86)\VMware\VMware Workstation>vmware-vdiskmanager.exe -R “D:\VMWare\Ubuntu\Ubuntu-000001.vmdk”
The virtual disk, ‘D:\VMWare\Ubuntu\Ubuntu-000001.vmdk’, was corrupted and has been successfully repaired.

What is actually being repaired

Worth understanding what you just fixed, because the filename is the clue. A vmdk ending -000001 is not the disk. It’s a delta link, the redo log created when you took a snapshot. The base disk goes read-only at that moment and every subsequent write lands in the delta as a 512-byte-granularity block, with a grain directory and grain tables mapping virtual offsets to positions in the delta file. Reading a sector means walking the chain from the newest link backwards until something claims it.

What -R repairs is that metadata rather than the filesystem inside the guest. If the grain tables and the descriptor disagree, usually because a write was interrupted by a host crash, a power loss or a full host volume, the disk is unreadable even though almost all of the data is intact. The repair rebuilds the tables from what it can find. It does nothing for corruption inside the guest filesystem, so run a chkdsk or fsck in the VM afterwards.

A few things worth knowing before you reach for this:

  • Copy the whole chain first. The base disk, every delta, and the small text descriptor files. Repairing one link of a broken chain is not always an improvement, and there is no undo.
  • The descriptor is plain text. Open a vmdk in a text editor and, for a chain, you’ll see the parentFileNameHint pointing at the link below it. Rename a file and you break that hint, which produces the same repair prompt with no actual corruption behind it.
  • The VM must be off. Not suspended. A suspended VM still holds a lock, and .lck directories left behind by a crashed host are a separate and commonly confused failure.
  • Deltas are why it was slow. Long snapshot chains cost you a lookup per link on every read. If performance was your original complaint, consolidating the snapshots will do more than defragmenting will. -d defragments and -k shrinks, but neither beats collapsing a chain you no longer need.