VM Fails to Power On with Error: "Both parent and child virtual disks are root links" (Error 69)
search cancel

VM Fails to Power On with Error: "Both parent and child virtual disks are root links" (Error 69)

book

Article ID: 449807

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

Symptoms:

  • A Virtual Machine fails to power on after an interrupted or failed snapshot consolidation task.

  • The vSphere Client displays the error: An error occurred while consolidating disks: Both parent and child virtual disks are root links.

  • The vmware.log file contains entries similar to:

    Both parent and child virtual disks are root links Failed to start the
    virtual machine. Module Disk power on failed. Cannot open the disk '/vmfs/volumes/vsan:52c2051334e6e884-############/6611b068-####-####-####-#############/vm_name_2-000002.vmdk' or one of the snapshot disks it depends on.

  • Under /var/run/log/hostd.log, there are similar errors:

    2026-07-16T23:53:10.741Z Er(163) Hostd[2099225]: [Originator@6876 sub=DiskLib opID=ml6lx7tc-10139406-auto-61bm7-h5:70888435-c5-01-01-01-01-3e-1165 sid=5267eaa8 user=vpxuser:<no user>] DISKLIB-LINK  : DiskLinkIsAttachPossible: Cannot attach 2 root links.
    2026-07-16T23:53:10.741Z In(166) Hostd[2099225]: [Originator@6876 sub=DiskLib opID=ml6lx7tc-10139406-auto-61bm7-h5:70888435-c5-01-01-01-01-3e-1165 sid=5267eaa8 user=vpxuser:<no user>] DISKLIB-LIB   : Failed to open '/vmfs/volumes/vsan:52c2051334e6e884-############/6611b068-####-####-####-#############/vm_name_2-000002.vmdk' with flags 0x403 Both parent and child virtual disks are root links (69).
    2026-07-16T23:53:10.741Z Wa(164) Hostd[2099225]: [Originator@6876 sub=Vmsvc.vm:/vmfs/volumes/vsan:52c2051334e6e884-############/6611b068-####-####-####-###########/vm-name.vmx opID=ml6lx7tc-10139406-auto-61bm7-h5:70888435-c5-01-01-01-01-3e-1165 sid=5267eaa8 user=vpxuser:<no user>] Load failed: cannot open /vmfs/volumes/vsan:52c2051334e6e884-############/6611b068-####-####-####-#############/vm_name_2-000002.vmdk (69): Both parent and child virtual disks are root links
  • Checking the VMDK descriptor files shows that both the base disk and the snapshot delta disks have parentCID and CID set to ffffffff:

    _2.000002.vmdk (Second snapshot)

    Disk DescriptorFile

    version=4
    encoding="UTF-8"
    CID=ffffffff
    parentCID=ffffffff
    createType="vsanSparse"
    parentFileNameHint="vm-name_2-000001.vmdk"

    Extent description

    RW 1677721600 VSANSPARSE "vsan://52c2051334e6e884-#############/2f57596a-####-####-####-###########"

    Change Tracking File

    changeTrackPath="vm-name_2-000002-ctk.vmdk"

    _2.000001.vmdk (First snapshot)
    +++++++++++++++++++++++++++++++++++++++++

    Disk DescriptorFile

    version=4
    encoding="UTF-8"
    CID=ffffffff
    parentCID=ffffffff
    createType="vsanSparse"
    parentFileNameHint="vm-name_2.vmdk"

    Extent description

    RW 1677721600 VSANSPARSE "vsan://52c2051334e6e884-#############/2f57596a-####-####-####-###########"

    Change Tracking File

    changeTrackPath="vm-name_2-000001-ctk.vmdk"

    _2.vmdk (Base disk)

    ==================================================

    Disk DescriptorFile

    version=4
    encoding="UTF-8"
    CID=ffffffff
    parentCID=ffffffff
    createType="vmfs"

    Extent description

    RW 1677721600 VMFS "vsan://52c2051334e6e884-#############/2f57596a-####-####-####-###########"

    Change Tracking File

    changeTrackPath="vm-name_2-ctk.vmdk"

Environment

  • VMware vSphere ESXi 7.x

  • VMware vSphere ESXi 8.x

Cause

The issue occurs when a snapshot consolidation or deletion process is interrupted (e.g., due to backup API timeouts, network drops, or process crashes).

During the commit phase, the hypervisor dynamically rewrites descriptor headers. If this is interrupted, the descriptor file may be left with uninitialized header values. Specifically, the parentCID is reset to ffffffff, which incorrectly defines the child delta disk as a "root link," causing a conflict in the storage dependency tree.

Resolution

To resolve the disk chain inconsistency and restore the VM power-on functionality, follow these manual descriptor repair steps:

WARNING: Before modifying .vmdk descriptor files, ensure you have a valid backup of the virtual machine. Incorrect manual edits can lead to data loss. Also, make sure the parent file hint matches the respective disk or this task might fail.

  1. Identify the Affected Disk Chain:

    • SSH into the ESXi host where the VM is registered.

    • Navigate to the VM's directory: cd /vmfs/volumes/Datastore_Name/VM_Folder/

    • Inspect both the base disk and the snapshot descriptors: cat VM_NAME.vmdk and cat VM_NAME-00000X.vmdk.

    • The Issue: Confirm that both the base disk and the child snapshot disks show CID=ffffffff and parentCID=ffffffff. This "root link" conflict prevents the hypervisor from identifying which disk is the parent.

  2. Manually Assign a New Base CID:

    • Open the base disk descriptor: vi VM_NAME.vmdk.

    • Locate the line CID=ffffffff.

    • Change the CID to a unique 8-digit hexadecimal value (e.g., CID=1a2b3c4d).

    • Save and exit (:wq!)

  3. Repair the Snapshot Inheritance:

    • Open the snapshot descriptor: vi VM_NAME-00000X.vmdk.

    • Update the parentCID to match the new base disk CID (e.g., parentCID=1a2b3c4d).

    • Provide the snapshot its own unique CID if it is also set to ffffffff.

    • Save and exit (:wq!)

  4. Force Metadata Refresh:

    • In the vSphere Client, take a temporary "dummy" snapshot of the VM. This action forces the ESXi host and vCenter to re-read the corrected descriptor files and update the storage metadata.
  5. Flatten and Consolidate:

    • Perform a "Delete All" snapshots operation. This will merge the corrected delta data into the base disk, clearing the corruption and consolidating the disk chain into a single consistent file.
  6. Power On:

    • Verify that the "Consolidation Needed" warning is gone and power on the VM.

Additional Information

Refer the following article for more details on similar cid pid mismatch, https://knowledge.broadcom.com/external/article/345254.