Australian cloud for business software — built and run in Sydney since 2003

+61 2 8282 5656
support@netleverage.com
Talk to an engineer
Talk to an engineer
NetLeverage
NetLeverage

VM will not power on: "The parent virtual disk has been modified since the child was created"

Troubleshooting article
VMwareBackup & RecoveryTroubleshooting

A virtual machine refuses to power on, or a snapshot consolidation fails, and the error says a parent disk "has been modified since the child was created". In the VM log the same fault appears as "Content ID mismatch". A failed consolidation can show it as msg.disklib.CID_MISMATCH, which KB 301128 explains as the CID and parentCID not matching in the descriptors.

In one plain sentence: every snapshot disk records a state identifier of the disk beneath it, and at power-on ESXi found the state identifier no longer matches, so it refuses to open the chain.

This article shows how to draw your chain, compare the state identifiers and judge which side of a broken pair changed, all without changing anything, and where diagnosis must stop for specialist recovery. A CID is not a checksum proving the disk contents are correct.

What is actually happening

A virtual disk is usually two things on the datastore: a small text descriptor and an extent that holds the data. For a base disk the extent is the -flat.vmdk file. For a snapshot disk it is a -delta.vmdk file, or a -sesparse.vmdk file on VMFS6 and on larger disks (KB 342618, KB 327862).

Four descriptor fields matter, as described in KB 345254:

  • CID is the disk's own content ID, eight lowercase hexadecimal digits.
  • parentCID is the content ID this disk expects its parent to have. A base disk has no parent and normally shows ffffffff.
  • parentFileNameHint is the name of the parent descriptor, used as a hint.
  • createType is the disk format: vmfs for a base disk, vmfsSparse for a snapshot disk (seSparse for the larger-disk format).

KB 345254 states that any time a virtual machine is powered on, the CID of the base or delta descriptor it uses is changed. KB 436761 adds that a host may assign a new CID when a snapshot disk is used by another VM. Every further power-on or attach attempt therefore makes diagnosis harder.

The extent line names the data file (KB 321422, KB 327862):

# base disk descriptor (excerpt)
createType="vmfs"
RW <sector count> VMFS "VM_Name-flat.vmdk"

# snapshot disk descriptor (excerpt)
parentFileNameHint="examplevm.vmdk"
RW <sector count> VMFSSPARSE "examplevm-000001-delta.vmdk"

Read the chain from the bottom up. The base disk sits at the bottom, and the disk the VM runs on sits at the top. At power-on ESXi compares each child's parentCID with its parent's CID. KB 345254 uses a three-descriptor example, listed here top first:

examplevm-000002.vmdk   CID=59fab513  parentCID=69a1c662   matches CID of the file below
examplevm-000001.vmdk   CID=69a1c662  parentCID=7b7644b2   must match CID of examplevm.vmdk
examplevm.vmdk          CID=12a9ffab  parentCID=ffffffff   base disk

Here the base disk's CID is 12a9ffab while its child expects 7b7644b2, so the middle pair is broken. A separate KB 345254 log example shows how the failure reads:

DISKLIB-LINK : Attach: Content ID mismatch (d0fdb25b != ef4854ee).
DISKLIB-CHAIN : "...examplevm.vmdk" : failed to open (The parent virtual disk has been modified since the child was created).
Module DiskEarly power on failed.

KB 345254 states that the CID mechanism is in place to prevent data corruption, so a mismatch is a protection that has fired.

How to prove it

Use existing approved read access on the registered host. These examples assume the failed VM is already powered off; do not shut down a running VM solely to follow this diagnostic section. Untested procedure, run in a lab first. Steps 1 to 6 only read log and descriptor text.

  1. Find the exact error. Search the current and the older logs, because logs rotate.
grep -i -e "content id" -e "modified since the child" "/vmfs/volumes/<datastore>/<vm folder>/"vmware*.log

When the cause is present you see two different IDs and a "failed to open" line naming a descriptor. If nothing matches, the available logs do not establish a CID fault; also investigate missing files and log retention rather than ruling a mismatch out.

  1. List the descriptors only. Data files carry -flat, -delta, -sesparse or -ctk in the name and can be very large, so the commands below must never touch them. Keep only the small descriptor files.
cd "/vmfs/volumes/<datastore>/<vm folder>"
ls -l *.vmdk | grep -v -e "-flat" -e "-delta" -e "-sesparse" -e "-ctk"
  1. Print the identity fields of those descriptors by name. Do not use *.vmdk here, because the pattern also matches the data files.
grep -E "CID|parentCID|parentFileNameHint|createType" examplevm.vmdk examplevm-000001.vmdk examplevm-000002.vmdk

  1. Draw the chain from the disk the .vmx file uses, following each parentFileNameHint to the base. KB 327862 warns the files are not always ordered numerically, so do not trust file numbers.

  2. Compare each pair: the child's parentCID against the parent's CID. Write down every pair that disagrees.

  3. Decide which side changed. The child's parentCID is the record of what the parent's CID was when the two were last matched. A parent whose CID now differs was changed afterwards: KB 345254 lists manual changes to the parent disk, power outages and interrupted Storage vMotion or migration, and KB 436761 describes an attach to another VM. Compare descriptor timestamps (ls -l), the power-on history in the vmware*.log files and the vCenter task and event history (KB 327862 points to logs and timestamps). If the evidence does not clearly say which side changed, stop and open a support case.

  4. Escalate additional chain tooling to the specialist handling the case. KB 309366 documents a chain check and KB 368913 a script with diagnostic and repair modes, but their availability is not proof of applicability or read-only behaviour on this build. This article withholds those executable examples rather than advising a one-off run of uncertain effect. Preserve the named-descriptor evidence for support; never select an automated repair mode to make identifiers agree.

Documented causes

The parent was changed after the child was created. KB 345254 gives manual modification of the parent disk, power outages, and interrupted Storage vMotion or migration while snapshots exist. Evidence: the two IDs in the log, one broken pair, and a matching timestamp, event or task. Reference: KB 345254, ESXi 7.0 and 8.0.

A snapshot disk was attached to another VM. KB 436761 describes this: the disk is attached elsewhere, that VM is powered on, and the disk is returned. The host assigns a new CID, so the child's record no longer matches. Evidence: events show the disk in use elsewhere. Reference: KB 436761, KB 345254 (both say not to do this).

A different fault: capacity mismatch. KB 345254 shows a separate error, "DISKLIB-LINK : Attach: the capacity of each link is different" with two sizes, and the client may show the disk at 0MB or 0B. KB 345254 links this to resizing a disk that has snapshots or growing an RDM during a snapshot commit. Correcting CIDs does not fix it.

A parent file is missing. This looks alike but is different. Evidence: a parentFileNameHint that names a file not in the folder, or the message "Cannot open the disk or one of the snapshot disks it depends on" (KB 321422). The KB 368913 script reports a missing parent but cannot fix it. Rebuilding is covered by KB 327862 (delta disks) and KB 321422 (base disks).

Recovery decisions and escalation

A CID mismatch is a reason to preserve evidence, not to make identifiers agree. Matching identifiers does not demonstrate that the underlying parent and child contents belong together. KB 345254 warns that subsequent power-on can make changes irreversible.

  1. Keep a failed, powered-off VM off and preserve the error, logs, configuration and per-disk chain map. Do not start it repeatedly to test guesses. For a VM still running with a failed consolidation, obtain specialist guidance before any shutdown or further disk operation.
  2. Open a Broadcom support case before production descriptor work. Establish whether a proven independent restore is preferable. A backup that can be listed or read is not yet a demonstrated application recovery.
  3. With specialist guidance, preserve every required configuration, descriptor and disk extent on independent storage, including disks outside the VM folder. Record identities, paths and chain relationships. Filenames and sizes are an inventory check, not integrity proof; define copy verification and isolated recovery checks before any edit. Keep originals untouched and rehearse on disposable copies only.
  4. Require a case-specific explanation of which content belongs in each parent/child relationship. Logs and timestamps are clues, not sufficient proof on their own. This guide intentionally withholds alternative CID-edit, reload and power-on recipes; a support article is not permission to choose one arbitrarily.
  5. Treat use of an older disk state as a separate data-loss decision. Document which later changes would be unavailable and obtain the data owner's acceptance of that loss window before specialist-directed recovery.
  6. Accept a recovered copy only after chain checks, guest checks, database/application validation and reconciliation of representative business records. A successful boot does not prove correct data. Confirm ongoing backup protection and a representative restore before considering the recovery complete.

No damaged-chain repair or restore has been lab tested for this article. Production changes require qualified case-specific review and a validated recovery route.

What not to do

  • Do not edit a live descriptor before a backup copy and a rehearsal exist. A wrong value cannot be taken back once the VM has written to the disk.
  • Do not make the numbers agree without knowing which side is right. That only silences the check.
  • Do not point commands at *.vmdk or edit the flat file. KB 321422 warns that changing the flat file may cause data loss. Treat delta files with the same caution.
  • Do not run a consolidation to clear a chain you have not drawn. We have seen a consolidation run out of order leave only a delta-named file as the VM's disk, with the original base disk name gone. Restoring the names took manual datastore work by ESXi engineers.
  • Do not attach a snapshotted disk to another VM (KB 436761, KB 345254) or resize a disk that has snapshots (KB 345254).
  • Do not treat snapshots as backups. KB 342618 says they are not and that VMware does not recommend manually modifying the disk chain.
  • Do not use the KB 321422 method on an encrypted disk. The article states it cannot recreate an encrypted descriptor.

Acceptance checklist

These are required checks, not completed test results.

  • [ ] Logs and named descriptors preserved; per-disk chains mapped.
  • [ ] All required extents preserved, including those outside the VM folder.
  • [ ] Support case and independently demonstrated recovery route established.
  • [ ] Case-specific parent/child content rationale reviewed.
  • [ ] Disposable-copy validation planned; originals untouched.
  • [ ] Any older-state data-loss window accepted by the owner.
  • [ ] Guest, application/business records and subsequent restore are acceptance gates.

Sources

  1. KB 345254, "The parent virtual disk has been modified since the child was created" error. https://knowledge.broadcom.com/external/article/345254 . Scope stated: ESXi 7.0 and 8.0 (Workstation versions also listed, out of scope here).
  2. KB 436761, Virtual machine fails to power on with "CID mismatch" error after attaching its snapshot VMDK to another VM. https://knowledge.broadcom.com/external/article/436761 . Scope: ESXi 7.0 and 8.0.
  3. KB 309366, Verifying a snapshot chain and cloning a Virtual Disk from snapshots. https://knowledge.broadcom.com/external/article/309366 . Scope: VMware vSphere ESXi, no version listed.
  4. KB 301128, Consolidating the VM disk fails with error: disks: msg.disklib.CID_MISMATCH. https://knowledge.broadcom.com/external/article/301128 . Scope: VMware vSphere ESXi, no version listed.
  5. KB 321422, Recreating a missing VMware virtual machine disk descriptor file (.vmdk). https://knowledge.broadcom.com/external/article/321422 . Scope: ESXi 7.x and 8.x.
  6. KB 327862, Recreating a missing virtual disk (VMDK) descriptor file for delta disks. https://knowledge.broadcom.com/external/article/327862 . Scope: ESXi 6.x, 7.x and 8.x.
  7. KB 368913, Locate and remediate CID/parentCID mismatches in snapshot descriptor files. https://knowledge.broadcom.com/external/article/368913 . Scope: ESXi 7.x and 8.x; vCenter Server 7.0 and 8.0.
  8. 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 and 9.x.