Which VMware Tools Repair a VMFS Datastore?
VMware ships two, and they operate on different objects. voma, the vSphere On-disk Metadata Analyzer, inspects VMFS filesystem metadata. partedUtil operates on the partition table of the block device the datastore lives inside. Neither one repairs failing hardware, and neither one can tell that the array under the LUN is degraded while it writes.
voma Command Modes for VMFS Metadata
voma picks what it examines with the -m module flag; -m vmfs targets a VMFS datastore. The -f flag decides whether the run reads or writes.
voma -m vmfs -f check- Inspects the VMFS metadata for inconsistencies and reports what it finds without modifying the disk. Check mode is the documented read-only pass, and on a datastore that matters it is the only pass to run until the block layer beneath it has been proven sound.
voma -m vmfs -f fix- Attempts to repair the inconsistencies that check mode found. Fix mode is documented behavior of the tool, not a guarantee that the datastore mounts afterward, and it inherits every error present in the block device underneath it.
Preconditions Before Running voma
VMware documents the state the volume has to be in before either mode is worth typing. The fourth precondition below is our own bench rule, not VMware's.
- Unmount the datastore, or power off and migrate every VM that lives on it. voma is documented to run against a volume that is not in service.
- Confirm the volume is fully accessible to the host. A LUN sitting in APD or PDL is not fully accessible, so it fails this precondition before a command is entered.
- On a spanned or multi-extent volume, verify every extent is present and accessible. voma does not reconstruct an extent the host cannot see; a missing extent is a block-layer problem and stays one through every filesystem tool VMware ships.
- Rule out media errors first. voma is built for minor logical inconsistencies. A volume backed by storage with underlying media errors or hardware failure is out of scope for it, and that covers a degraded array, a failing member drive, and a LUN returning SCSI sense.
voma Fix Mode Commits Metadata Writes
-f fix rewrites filesystem metadata structures on the volume it is inspecting. That is the correct behavior when the inconsistency is logical and the storage under it is sound. On a degraded array it is the wrong behavior: the blocks voma reads back are reconstructed from parity, and on a degraded array that parity can already be wrong, so the metadata fix gets committed on top of an inaccurate picture, onto the same member drives a later reconstruction depends on.
Fix mode inherits the URE problem too. Every block the missing member held gets computed from the corresponding stripe units on the survivors, and rebuilding that member forces a full-surface read of every one of them. Consumer drives are rated at roughly one Unrecoverable Read Error per 10^14 bits read, about 12.5 TB, so a stripe reconstructed from a bad read reaches voma looking like filesystem corruption. Fix mode will write a correction for it. That arithmetic is the whole argument for imaging a degraded array instead of rebuilding it, with ddrescue or PC-3000 hardware, before any repair command runs.
Why Can't partedUtil Repair VMFS Metadata?
partedUtil never reaches the filesystem. It operates strictly on the partition table, the GPT written on the block device, and its documented subcommands do exactly that: partedUtil getptbl reads the current table, setptbl writes a new one, and fix attempts to repair a damaged GPT header. Files, folders, and .vmdk extents sit outside its scope. Its job is defining where the partition begins and ends.
That boundary is where the self-inflicted ESXi partition failure happens. Administrators widely report recreating a partition entry with setptbl and a starting sector that does not match the original. The filesystem inside is untouched, but the host now looks for the VMFS volume header at the wrong offset, so the header is unaddressable and the datastore will not mount. The answer is not a second repair command. It is recovering the original boundary from a read-only image of the device, which is server storage recovery work.
VMFS 5 and VMFS 6 Differences That Change a Repair
A repair attempt against VMFS 6 is not the same job as one against VMFS 5. Three differences change what a tool can get back.
| Behavior | VMFS 5 | VMFS 6 |
|---|
| Space reclamation | Blocks freed by a deletion commonly survive long enough that carving them back succeeds. | Automatic asynchronous UNMAP sends SCSI UNMAP to the array, so deleted blocks get reclaimed quickly and carving after a deletion is far less likely to succeed. |
| Snapshot deltas | vmfsSparse deltas. | seSparse deltas for every snapshot, which changes how a tool walks the chain. |
| Sector format and partition layout | Newly created volumes use GPT; volumes upgraded from VMFS3 keep MBR until they are expanded past 2 TB. | 512e and 4Kn support with a differing GPT layout, so repair software parses the geometry with updated offset expectations. |
Automatic UNMAP is the difference that decides whether a deleted VM is still on the storage at all. On VMFS 6 the window between deleting a VM and losing the blocks it occupied is short, which is why deleted VMDK recovery on a VMFS 6 datastore is a race the host wins if you leave it running.
Where Admin Repair Ends and Lab Reconstruction Starts
Admin-side, in place. The host boots, the controller reports the array healthy, and the inconsistency is purely logical, the kind a sudden power loss leaves behind. Unmount the datastore, run voma -m vmfs -f check, read what it reports, and decide from there whether fix mode is warranted.
Lab-side, from cloned members. The array is degraded, drives have failed, the controller is offline, or the block device is returning read errors and SCSI sense. Every member is imaged read-only first on PC-3000 hardware or a DeepSpar Disk Imager, the array geometry is then reconstructed in software with Data Extractor Express RAID Edition against those image files, and only then does a filesystem tool get pointed at the reconstructed volume. Running voma against a live degraded array skips the step that makes its output mean anything.
Both halves of that boundary run in-house at our Austin lab, alongside the rest of our array reconstruction work. No diagnostic fee, and no recovery fee if the data does not come back.
