VMware Snapshot Chain Broken: Consolidation and CID Mismatch Errors

A VMware virtual machine with snapshots is not stored in one disk file but in a chain: the base disk, and one delta file for every snapshot, each holding only the blocks that changed after it was taken. When one link of that chain is damaged, missing or out of step, the VM refuses to power on, consolidation fails, or the backup job starts failing every night. The data is almost always still there. This guide explains how the chain works, what the common errors mean, which fixes are safe, and how the data is recovered when the chain cannot be repaired in place.

Every virtual disk has two parts: a small text descriptor (server.vmdk) and the data file (server-flat.vmdk for the base disk). Taking a snapshot freezes the base disk and creates a new pair, server-000001.vmdk and its delta file, server-000001-delta.vmdk or server-000001-sesparse.vmdk depending on the format. From then on every write goes to the delta, and reads that are not in the delta fall through to the parent. A second snapshot adds server-000002, and so on. The .vmsd file lists the snapshots for the Snapshot Manager, and the .vmx file says which disk in the chain the VM is running on.

Each descriptor carries a content ID (CID) and, for a delta, the CID of its parent (parentCID) and the parent's file name (parentFileNameHint). When ESXi opens the chain, it checks that every child's parentCID matches the parent's CID. That check is what produces most of the frightening errors, and it is also what protects the data from being combined in the wrong order.

'Virtual machine disks consolidation is needed' means a snapshot was deleted in the Snapshot Manager but its delta files were not merged into the parent, very often because a backup job was interrupted or a backup proxy still has the disk attached. Consolidation usually succeeds once the cause is gone: no backup job running, no backup proxy VM holding a hot-added disk, and enough free space on the datastore for the merge.

'The parent virtual disk has been modified since the child was created' is a CID mismatch: the parent's CID no longer matches the parentCID recorded in the child. The harmless cause is a descriptor that was edited, restored or rewritten. The dangerous cause is a parent disk that really was written to, for example when someone pointed the VM or another VM at the base disk directly. In that case the delta no longer fits the parent, and forcing the chain together produces a corrupt file system.

'Cannot open the disk ... or one of the snapshot disks it depends on' and 'File not found' mean a link is missing: a descriptor or a delta file was deleted, moved, renamed, or is on a datastore that is not mounted. 'Failed to lock the file' means another host or a backup proxy still has the disk open.

Before any fix, copy every file in the VM's folder, above all the .vmdk descriptors, the -flat, -delta and -sesparse files, the .vmsd and the .vmx, to another datastore or off the host. The descriptors are a few hundred bytes each; keep a copy of them even if the large files cannot be copied yet. Do not delete snapshot files that look old or orphaned, do not click Delete All in the Snapshot Manager while the chain is broken, do not create a new snapshot, and do not power on the VM against the base disk 'just to see': every one of these can change the parent and make the CID mismatch real.

If the problem is free space, add space to the datastore or move other VMs away; do not free space by deleting files from this VM's folder.

Read the descriptors with a text viewer and draw the chain on paper: which file names which parent, which CIDs match, and which disk the .vmx points to. Most broken chains are a wrong parentFileNameHint after a rename or move, or a .vmx that points at the base disk instead of the newest delta; correcting the text in a copy of the descriptor fixes them without touching any data.

If the chain opens, the safest way to get a clean disk is not to consolidate in place but to clone the chain into a new disk with vmkfstools -i, pointing it at the newest descriptor. The clone reads the whole chain and writes a single new disk, and the original files stay as they were if anything goes wrong.

Editing a child's parentCID to match the parent is a standard repair, but only when you are sure the parent was not written to after the snapshot. If you are not sure, clone first and check the file system in the clone before touching the originals. A missing descriptor can be recreated for an existing -flat or delta file, with exactly the original size and geometry; a wrong size here makes the disk unreadable rather than recovering it.

When a delta file is lost or damaged, or the parent really was changed, the data is recovered from what remains. The base -flat.vmdk alone still holds the complete disk as it was when the first snapshot was taken, and each surviving delta adds the blocks changed after it. Recovery reads the base disk and the deltas directly, applies them in the right order, and reads the file systems inside to bring back the files and databases. Where a delta is missing in the middle, the newer deltas are still useful for the blocks they contain, and the result is checked file by file rather than trusted as a whole.

This is also why a damaged or ransomware-encrypted snapshot chain is rarely a total loss: the base disk is usually the largest file and, for large disks, often only partly encrypted.

AS VMware Recovery opens VMDK and Hyper-V disks directly on a Windows PC, follows snapshot chains automatically, finds a parent by its identity when files were renamed or moved, rebuilds an empty or damaged descriptor from the data file, and recovers files from the current state or any older snapshot. The free edition opens the disk and its snapshots, runs every scan and previews every file before you buy.

For production servers, VMFS datastores that will not mount and VMs with databases inside, our VMware data recovery service does the work remotely or in our laboratory. We have recovered many virtual machines; contact us for a free assessment, and if no data can be recovered, there is no charge. Afterwards, the lasting fix is simple: keep snapshots for hours or days, not months, check for 'consolidation needed' after every backup run, and remember that a snapshot is not a backup.