The -000001.vmdk and delta files in a VM folder: what each one is

You look in a VM folder and find files you did not create: names ending in -flat.vmdk, -000001.vmdk, -000001-delta.vmdk or -000001-sesparse.vmdk, plus .vmsd, .vmsn and -ctk.vmdk. Perhaps vCenter shows "Needs Consolidation", or a snapshot has vanished from Snapshot Manager, and you need to know which files matter.

A snapshot does not copy your disk. It freezes the existing disk file and starts a new, small file for what the guest writes from then on. Each new file points back to the one before it, forming a chain.

This article explains each file, the two delta formats, and how to read the chain with file listings and named descriptor files. You need a shell on the ESXi host for steps 1 to 5; the datastore browser cannot show descriptor contents. Every command in "How to prove it" only reads.

What is actually happening

Each virtual disk is a pair of files. The descriptor is a small text file, for example vmname.vmdk, that describes the disk and names its parent. The data sits in a second file; for the base disk that is vmname-flat.vmdk. KB 337269 gives the delta pattern as VM_NAME-00000N-delta.vmdk. KB 342618 says a snapshot creates, for each virtual disk, a .vmdk descriptor and a -delta.vmdk file, called child disks or delta links, each recording changes back toward the parent.

Per KB 342618 the .vmsd is a database of snapshot information and the main source for Snapshot Manager, and the .vmsn holds the VM's configuration and optionally its active state; memory snapshots need it to revert to a running state. The page writes the name as Snapshot.vmsn; the exact name with a number in the table is illustrative. KB 320557 says every virtual disk and snapshot disk has a .ctk file. Changed block tracking (CBT) is how your backup product asks which blocks changed.

VMFSsparse and SEsparse

The two delta formats depend on the datastore. The Broadcom TechDocs page "Snapshot Formats on VMFS" (vSphere 7.0 storage guide, repeated in the 8.0 guide) states that VMFSsparse is used on VMFS5 for virtual disks smaller than 2 TB, is not available on VMFS6, and that SEsparse is the default for all delta disks on VMFS6. On VMFS5 it says "SEsparse is used for virtual disks of the size 2 TB and larger", while its table says "larger than 2 TB". KB 342618 says "larger than 2TB". The pages differ at exactly 2 TB, so check a disk of about that size rather than assume. The TechDocs page also says "You cannot mix VMFSsparse redo-logs with SEsparse redo-logs in the same hierarchy", and that migrating a VM with a VMFSsparse snapshot to VMFS6 changes the snapshot to SEsparse. On VMFS6 expect -sesparse.vmdk files.

A healthy chain and a broken one

The chain is linear: the VM writes to the newest child, which points to its parent, back to the -flat file. A delta grows while the VM runs on the snapshot, up to the size of the base disk plus overhead (KB 342618). KB 337269 (titled for vSphere 5.x) says delta numbers use the first free slot, so the number does not follow parent and child order; KB 342618 agrees that "The file names are chosen based on filename availability". In its example, after a revert, -000004 is the child of -000005, which is the child of -000003. A healthy chain does not need out-of-order numbers.

Every descriptor carries a content ID (CID) and a parentCID that must equal its parent's CID. KB 345254 (ESXi 7.0 and 8.0) shows a healthy pair, quoted from the page:

examplevm.vmdk          CID=7b7644b2   parentCID=ffffffff
examplevm-000001.vmdk   CID=69a1c662   parentCID=7b7644b2
                        parentFileNameHint="examplevm.vmdk"

The base disk has parentCID=ffffffff, meaning no parent. The child's parentCID equals the base CID. In a broken pair the child parentCID no longer equals the parent CID; the page's example pairs a base CID of 12a9ffab with a child parentCID of 7b7644b2. vmware.log then shows the page's line:

DISKLIB-LINK : Attach: Content ID mismatch (d0fdb25b != ef4854ee).

and the power-on or consolidation error reads "The parent virtual disk has been modified since the child was created". A CID changes at power-on, so a changed CID is not itself a fault. use the VM configuration and per-disk descriptor chain alongside vCenter metadata to establish active references. An apparently unreferenced delta needs investigation of other consumers before it can be called orphaned.

How to prove it

These steps read only. They are untested procedures in your environment: run them in a lab first where possible. Work from the VM folder.

1. List the folder.

cd /vmfs/volumes/<datastore>/<vm>/
ls -la

Healthy: one -flat.vmdk per disk and one descriptor plus one delta or sesparse file per snapshot disk, with times that fit your backup dates. Suspect: delta files with old times that no running disk uses, or -000001-ctk.vmdk files left over. KB 320557 says after a successful backup and full consolidation no snapshot-related .ctk files should remain.

2. Find the disks the VM uses (the command form from KB 337269).

cat vmname.vmx | grep scsi | grep -E "vmdk|present"

The disk named here is the top of the chain.

3. Read the snapshot database.

cat vmname.vmsd

Each snapshot has a snapshotX.filename (the .vmsn) and snapshotX.diskY.fileName entry. KB 337269 warns that the disk name there is not the child file name. One snapshot can cover multiple virtual disks, so fewer snapshot entries than delta files does not prove disagreement. Reconcile the active references and parent chain separately for each disk (KB 342618). A failed merge can leave files behind (KB 316414), but counts alone do not identify them.

4. Read the descriptors only. Descriptor files are the small text files: vmname.vmdk and vmname-00000N.vmdk. Never run grep or cat on any file ending -flat.vmdk, -delta.vmdk, -sesparse.vmdk or -ctk.vmdk; those are data files that can be hundreds of gigabytes, and reading them loads the datastore and prints binary.

for f in vmname.vmdk vmname-0000*.vmdk; do
  case "$f" in *-flat.vmdk|*-delta.vmdk|*-sesparse.vmdk|*-ctk.vmdk) continue;; esac
  echo "== $f"; grep -E "^(CID|parentCID|parentFileNameHint)" "$f"
done

This loop is not from VMware documentation; it only reads descriptor text and skips data files by name. Healthy output matches the pair above. Broken output shows a child whose parentCID differs from the parent's CID, or a parentFileNameHint naming a file that is not in the folder.

5. Preserve the descriptor comparison for specialist assessment. The cited vendor pages describe additional chain-opening tools, but do not establish their safety on a live disk for every build. Executable chain-opening examples are withheld here; do not power off production solely to try a historical diagnostic example.

6. If deltas are locked, find the owner. KB 314365 uses vmfsfilelockinfo -p /vmfs/volumes/<UUID>/<vm>/<vm>-000001-delta.vmdk on hosts before ESXi 8.0 U2, and says 8.0 U2 onwards shows the owner in the vSphere Client.

7. Total the snapshot size. KB 316414 gives:

ls -la | grep -E 'delta|sesparse' | awk '{ SUM += $5/1024/1024 } END {printf "Total Snapshot Size: %.2f MB\n", SUM+0}'

The causes

A snapshot is still there. The chain is intact and nothing removed the snapshot. Evidence: the .vmsd lists it. KB 318825 (ESXi and vCenter 8.x and 9.x only; do not assume these for 7.x) supports 32 snapshots in a chain, 2 to 3 for performance, and no single snapshot kept beyond 72 hours.

A removal failed part way. KB 316414 says removal can fail on network loss, lock timeouts, a host crash or a power interruption, and that if files remain or consolidation fails "manual intervention may be required". Evidence: steps 1 and 3 disagree, and vCenter shows "Needs Consolidation".

The parent changed after the child was made. A CID mismatch from step 4 or 5. KB 345254 gives the message and a repair procedure. Its steps are, in its words, "potentially hazardous for your environment if they are not followed exactly". That procedure is DESTRUCTIVE (VM off, verified backup first, second pair of eyes) and this article does not cover it.

Recovery decisions and escalation

The file inventory is a diagnostic aid, not permission to remove files. Preserve the VM configuration, named descriptors, logs and a per-disk chain map outside the affected datastore before choosing a recovery route.

A healthy VM with two virtual disks can create separate delta files for the same snapshot. Compare each active disk's references and parent chain, not the total number of snapshots with the total number of files. Conversely, an apparently unreferenced file is only a candidate for further investigation: check other VM/proxy references and backup operations before calling it orphaned. Never delete it from a filename or count alone.

If the chain is consistent and snapshot removal is intended, a qualified operator must first confirm a demonstrated restore route, sufficient capacity, no conflicting job or holder, and agreement about the exact restore points to discard. Delete All removes all snapshot restore points; consolidation and deletion are state-changing operations whose impact on other VMs needs assessment. Select the applicable vendor workflow for the storage type and build rather than trying both operations automatically.

If a merge fails, a parent is missing, identifiers disagree or ownership is uncertain, stop. Preserve all chain components and escalate to Broadcom and the backup supplier. Failed consolidation does not justify editing CIDs, moving metadata, deleting deltas or booting an older disk. Those are separate recovery-case decisions requiring specialist direction and disposable-copy validation.

Acceptance is the intended per-disk chain and retained snapshot state, successful guest/application checks and a representative restore after protection resumes. A clean directory listing alone is insufficient. No recovery procedure here has been lab validated.

What not to do

• Do not delete a -delta.vmdk or -sesparse.vmdk because it looks old. It may hold the only copy of recent writes.
• Do not delete the -flat.vmdk or its descriptor to free space. Every child in the chain is useless without it.
• Do not edit CIDs because a mismatch message appeared. Prove the chain first.
• Do not hunt for .lck files on VMFS. KB 314365 says VMFS has none; locks sit in its metadata.
• Do not treat a snapshot as a backup, or leave one running for days.

Acceptance checklist

These are required checks, not completed test results.

• [ ] Per-disk chain mapped from configuration and named descriptors.
• [ ] Healthy multidisk count difference distinguished from a suspect reference.
• [ ] Candidate orphan checked against other consumers; no files deleted by inference.
• [ ] Evidence and independent recovery route preserved.
• [ ] Failed merge or uncertain chain escalated without manual edits.
• [ ] Intended chain, application correctness and subsequent recovery verified.

Sources

1. KB 342618, Overview of virtual machine snapshots in vSphere, https://knowledge.broadcom.com/external/article/342618. Scope: vCenter Server and ESXi 7.x, 8.x, 9.x.
2. KB 318825, Best practices for using VMware snapshots in the vSphere environment, https://knowledge.broadcom.com/external/article/318825. Scope: ESXi 8.x, 9.x; vCenter 8.x, 9.x.
3. KB 316414, How to calculate current snapshot size, estimate consolidation times, and understand performance factors affecting the consolidation process, https://knowledge.broadcom.com/external/article/316414. Scope: vSphere 6.x, 7.x, 8.x, 9.x.
4. KB 316554, Thinly provisioned Virtual Disks inflates to a larger size during snapshot removal process, https://knowledge.broadcom.com/external/article/316554. Scope: ESXi 7.0.0, 6.7, 6.5, 6.0; improved in 7.0 U1.
5. KB 337269, Understanding the relationship between Snapshot Manager and the backing files in vSphere 5.x, https://knowledge.broadcom.com/external/article/337269. Scope: titled vSphere 5.x; no build range stated.
6. KB 345254, "The parent virtual disk has been modified since the child was created" error, https://knowledge.broadcom.com/external/article/345254. Scope: ESXi 7.0 and 8.0.
7. KB 320557, Changed Block Tracking (CBT) on virtual machines, https://knowledge.broadcom.com/external/article/320557. Scope: ESXi 8.x, 9.x.
8. KB 314365, Investigating Virtual Machine file locks on ESXi Host(s), https://knowledge.broadcom.com/external/article/314365. Scope: ESXi 7.x, 8.x, 9.x.
9. Snapshot Formats on VMFS, vSphere 7.0 Storage guide, https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vsphere-storage/working-with-datastores-in-vsphere-storage-environment/vsphere-vmfs-datastore-concepts-and-operations/snapshot-formats.html. Scope: vSphere 7.0.
10. Snapshot Formats on VMFS, in vSphere VMFS Datastore Concepts and Operations, vSphere 8.0 Storage guide, https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-storage/working-with-datastores-in-vsphere-storage-environment/vsphere-vmfs-datastore-concepts-and-operations.html. Scope: vSphere 8.0.