Monday 24 August 2015

Resolved: Resolving the CID mismatch error: The parent virtual disk has been modified since the child was created.

When performing snapshotting operations within VMware a delta disk is created for all compatible disks. The delta vmdk file holds all of the changes made from the point-in-time that the snapshot was performed.

Typically you would have a base disk e.g. CDRIVE.VMDK - the delta disk would look something like CDRIVE-0000000001.vmdk, incrementing the integer with each snapshot taken.

I came accross a situation the other day where VMWare was complaning that my the parent disk had a different CID (a unique identifer for a disk / VMDK that changes whenever turned on):

"Resolving the CID mismatch error: The parent virtual disk has been modified since the child was created"

I was unable to consolidate the snapshots with the VMWare client - in they weren't even visable within the client - I had to browse the datastore to find them.

This can be caused by problems with vSphere Replication, adding snapshotted disks to an existing VM, expanding disks with existing snaphsots and so on.

In order to remedy this we should firstly identify the CID of each disk - the CID is located in the disks discriptor file. Lets say we have the following parent disk:

CDRIVE.VMDK

and the following delta (snaphots) drives:

CDRIVE-00000001-DELTA.VMDK
CDRIVE-00000002-DELTA.VMDK

* Warning: Do not run 'cat' on any files with *flat* or *delta* in their title - these are NOT discriptor files *

*** BEFORE PERFORMING ANY OF THE BELOW ENSURE YOU BACKUP ALL OF THE FILES AFFECTED AS THIS OPERATION HAS THE POTENTIAL OF CORRUPTING THE DISKS! ***

We will firstly identify the CID of all of the VMDK's:

SSH into the ESXI host and cd to the vm's directory e.g.:

cd /vmfs/datastore1/myvm

There will be an assortment of files - but we are looking for CDRIVE-00000001.VMDK in our case.

To view the descriptor file we should run something like:

cat CDRIVE.VMDK

We might get something like:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=2776c5f6
parentCID=ffffffff

The parentCID for this disk is 'ffffffff' informing us that this is the the highest disk in the hierarchy.

The CID '2776c5f6' is what the delta disk CDRIVE-00000001.VMDK should have for it's 'parentCID' attribute, so we will now check the descriptor file for 'CDRIVE-00000001.VMDK':

cat CDRIVE-00000001.VMDK

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=45784545j
parentCID=2776c5f6

As expected the parentCID is correct - now CDRIVE-00000002.VMDK's parentSID attribute should be that of CDRIVE-00000001.VMDK's CID (45784545j)

So we proceed by checking CDRIVE-00000002.VMDK:

cat CDRIVE-00000002.VMDK

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=KKF88944
parentCID=3HHF343F

Although we find that CDRIVE-00000002.VMDK's parentCID does not match that of CDRIVE-00000001.VMDK and hence is where the break in the chain is. So we should change CDRIVE-00000002.VMDK's parentCID to '45784545j'.

We can now ensure that the snapshots are valid with the following command against the highest level snapshot e.g.:

vmkfstools -e CDRIVE-00000001.VMDK

1 comment:

  1. It was very helpful as my daily replication job getting failed due to unexpected CID mismatch from parent to child disk . Thanks for the post :)

    ReplyDelete