VOMA is the vSphere On-disk Metadata Analyzer. It examines the structural metadata of a VMFS datastore and reports inconsistencies in elements such as allocation, directory connectivity, heartbeat information, and filesystem structures. It is not a performance benchmark, a VMDK content checker, or a general tool for repairing guest filesystems.
VOMA must be treated as a storage-recovery instrument. The datastore should not be in active use, and current backups should exist before a check—especially before any repair mode is considered.
When VOMA Is Relevant
Broadcom’s current VOMA procedure identifies situations such as:
- VMFS metadata errors in
vmkernel.log; - files on a VMFS volume becoming inaccessible when not locked by another host;
- corrupt heartbeat or invalid-metadata messages;
- partition-table investigation or recovery under supported guidance.
A virtual machine that fails for an ordinary guest error, invalid VMX setting, missing ISO, unavailable passthrough device, or application problem does not automatically need a datastore scan. First prove that the evidence points to VMFS metadata.
VOMA Does Not Check Guest Data
VMFS stores virtual-machine files, but VOMA checks the datastore filesystem’s metadata. It does not validate NTFS, ReFS, ext4, XFS, Oracle blocks, or application consistency inside a VMDK. Guest tools such as chkdsk, fsck, database consistency checks, and backup verification address different layers.
It also cannot certify that a VMDK chain is logically correct merely because VMFS metadata is consistent. Snapshot descriptors, VM configuration, and guest data require their own checks.
Prepare the Datastore
Do not run VOMA against a busy shared datastore. Inventory every registered VM, template, ISO, swap file, scratch location, core dump, HA heartbeat, and host reference using the volume. Migrate or shut down workloads according to a change plan and ensure no host is writing to the device.
Then:
- confirm recent, independently usable backups;
- collect relevant host logs and storage alerts;
- identify the exact canonical device and VMFS partition;
- verify multipath health and device identity from the intended host;
- unmount or otherwise quiesce the datastore according to the supported procedure;
- store VOMA output on a different datastore or temporary filesystem.
Never copy a device identifier from another environment. A wrong naa target can point the analysis at unrelated storage.
Run Check Mode First
Broadcom documents check syntax in this form:
voma -m vmfs -f check -a \
-d /vmfs/devices/disks/naa.example:1 \
-s /tmp/voma-analysis.txt
Replace the placeholder with the verified device and partition. Save the log outside the volume being checked. Review the ESXi version’s built-in help and the current Broadcom KB because modes and supported behaviour vary across releases.
Check mode reports findings; it should not be treated as permission to run repair automatically. Preserve the full output, device information, ESXi build, storage topology, and surrounding log timestamps for support analysis.
Understand the Risk Warning
Broadcom warns that shutting down a VM whose files depend on certain corrupt metadata can make that VM and its data permanently unavailable. If a VM is still running while storage errors appear, opening a support case and capturing a recoverable backup may be safer than powering it off simply to run VOMA.
Repair mode changes on-disk structures. Run it only with validated backups and a case-specific plan from Broadcom support or equivalent qualified storage expertise. Repeated repair attempts can make later forensic recovery harder.
Version Mismatch Can Create False Findings
VOMA output must be interpreted in the context of every host sharing the datastore. Broadcom documents a case in which a check from a pre-ESXi 8.0 Update 3 host can incorrectly report .unmap.sf corruption on a datastore also used by an 8.0 U3 host. That does not mean all VOMA errors are false; it means host-build compatibility is part of the evidence.
Before escalating a finding, record which host ran the check, which builds can access the datastore, and whether the reported structure is associated with a known version-specific behaviour.
After the Check
If no inconsistencies are reported, remount and return the datastore through the approved change procedure, then continue investigating the original symptom at the correct layer. If errors are reported, keep the datastore quiescent, protect the log and backups, and obtain a repair decision based on the exact findings.
After any authorised repair, rescan in check mode, review VMFS and storage logs, validate inventory and snapshot chains, and test critical VMs one at a time. A clean VOMA result is one recovery gate, not proof that every application is consistent.
VOMA is valuable because it examines metadata that ordinary file browsing cannot. Its safety comes from using it only when evidence points to VMFS, proving the target device, eliminating active writers, preserving backups, and separating diagnosis from repair.
