Handle a VMware VM with an inconsistent snapshot chain

Objective

Protect a VMware VM whose snapshot chain can no longer be opened or consolidated, preserve the data before any manipulation, identify the missing or inconsistent link, and prefer a supported recovery method such as restore or clone when the chain cannot be repaired safely.

Prerequisites

A recent backup or a complete copy of the VM folder on storage with sufficient free space.
vCenter access and ESXi SSH access for read-only diagnostics.
VM name, datastore, folder path, and expected disk list.
A maintenance window to stop writes or power off the VM when required.
Enough capacity to create a clone or restore a replacement VM.

Step-by-step procedure

Stop automatic operations

Temporarily disable backup, replication, automatic snapshots, and consolidation tasks for the VM. If operationally acceptable, power it off to freeze the disk state. Record the time and the last successful operation before inspecting the chain.

Expected result

No automated task changes the VMDK files during analysis.

Preserve a copy before editing

Copy the complete VM folder when space allows, or verify that a recent backup can be restored. Copying only descriptor files does not protect the data if a later mistake affects delta or flat disks. Keep the safety copy independent from the affected datastore when possible.

Expected result

A recovery path exists before any chain manipulation.

List every file and locate breaks

Inventory files by name, size, and timestamp. Look for a snapshot sequence that skips a level, a descriptor without its data extent, or a data extent without its descriptor. Do not assume that a missing number alone proves corruption; correlate the file list with the VM configuration and descriptors.

ls -lah /vmfs/volumes/<DATASTORE>/<VM-DIR>/

find /vmfs/volumes/<DATASTORE>/<VM-DIR>/ -maxdepth 1 -name "*.vmdk" -type f -print

Expected result

A physical inventory of the VM folder is available before logical analysis.

Identify the disk actually attached to the VM

Use the VMX configuration or vCenter information to identify the descriptor currently attached to each virtual disk. A VM can have several controllers and independent chains, so assess every disk separately before attempting a repair.

grep -E "scsi[0-9]+:[0-9]+.fileName|sata[0-9]+:[0-9]+.fileName|nvme[0-9]+:[0-9]+.fileName" /vmfs/volumes/<DATASTORE>/<VM-DIR>/<VM>.vmx

Expected result

The current entry point of every disk chain is known.

Read descriptors without modifying them

Read the small VMDK descriptor files and record CID, parentCID, and parentFileNameHint. Build the chain from the current disk back to the base disk and verify each parent-child relationship. If a referenced parent is missing, search backups and copies before considering manual reconstruction.

grep -E "^(CID|parentCID|parentFileNameHint)" /vmfs/volumes/<DATASTORE>/<VM-DIR>/<DISK>.vmdk

Expected result

The parent-child chain is documented and the first inconsistent link is identified.

Validate the chain with vmkfstools

Run vmkfstools -e against the descriptor currently attached to the VM and preserve the exact output. A CID mismatch, missing parent, or invalid parameter should be correlated with the files and logs before any correction is made.

vmkfstools -e /vmfs/volumes/<DATASTORE>/<VM-DIR>/<CURRENT-DISK>.vmdk

Expected result

VMware chain consistency is known and the exact error is preserved.

Review vmware.log and vCenter tasks

Find the first error at the time the issue appeared, such as snapshot deletion, consolidation, Storage vMotion, a full datastore, or a manual copy. vmware.log often identifies the exact file that DISKLIB cannot open.

grep -Ei "DISKLIB|CID|parent|consolidat|snapshot" /vmfs/volumes/<DATASTORE>/<VM-DIR>/vmware.log | tail -n 100

Expected result

The chain error is correlated with a specific operation or file.

Prefer restore or clone before manual descriptor editing

If a required snapshot is missing, restore a recent backup into a new VM. If the chain is complete but vSphere consolidation fails, a supported clone may rebuild a clean chain. Edit descriptors only on a copy and only when the cause is fully understood or with vendor support.

Expected result

The selected recovery method minimizes risk to the original data.

Consolidate or clone with sufficient headroom

Check free datastore space and I/O capacity before consolidation. A large chain can take time and generate substantial load, so monitor the task and avoid cancelling it arbitrarily. Keep the original files until the recovered VM has been fully validated.

df -h

esxcli storage filesystem list

Expected result

The recovery task completes without exhausting the datastore.

Validate the recovered VM and create a new full backup

Start the recovered VM on an appropriate network, check disks, services, and applications, and confirm that vCenter no longer reports consolidation required. Then run a new full backup and, when possible, a restore test before deleting the safety copy.

Expected result

The VM runs from a clean chain and a new full backup succeeds.

Validation

The procedure is validated when:

vmkfstools can open the final disk chain without error.
The VM starts and its volumes and applications are coherent.
vCenter no longer reports consolidation required.
A new full backup and a restore test succeed.

Rollback

Return to the complete VM-folder copy or backup if a recovery attempt fails.
Do not delete original snapshot files until the recovered VM is validated.
If a clone fails, stop the attempt and preserve the source and logs before choosing another strategy.

Troubleshooting / common errors

If a referenced parent disk is missing, stop manual edits and prioritize recovery from a coherent backup.
If consolidation fails because of free space, address datastore capacity before repeating the task.
If vmkfstools and vCenter disagree, preserve the evidence and involve VMware/Broadcom support before editing descriptors.