The parent virtual disk has been modified since the child was created

[dan123123]

Hi,

I need some assistance please.

A server was accidentally started up with the base disk selected rather than it's delta. As soon as i noticed i shut it down and reconfigured it to use the latest delta.

But i now get the error:

The parent virtual disk has been modified since the child was created.

the file list is this:

SHAREPOINTDB00_1.vmdk

SHAREPOINTDB00_1-000001.vmdk

SHAREPOINTDB00_1-000001-sesparse.vmdk

SHAREPOINTDB00_1-000002.vmdk

SHAREPOINTDB00_1-000002-sesparse.vmdk

SHAREPOINTDB00_1-flat.vmdk

the vmdk files are attached

am i right in thinking that the SHAREPOINTDB00_1-000001.vmdk is the one that should be attached to the VM?

and should i change the cid in the base file's configuration or use the new CID in the delta's config?

I'm hoping If i edit and upload these files, then take a vm snapshot the current data will stay as is? I have not even been able to copy the vmdk in esxi to keep any type of backup

Thanks

[continuum]

"SHAREPOINTDB00_1-000001.vmdk" is child of "SHAREPOINTDB00_1-000002.vmdk" which is child of "SHAREPOINTDB00_1.vmdk"
So your idea to configure "SHAREPOINTDB00_1-000001.vmdk" is ok.
It does not matter wether you edit parentCID of "SHAREPOINTDB00_2-000001.vmdk" or CID of "SHAREPOINTDB00_1.vmdk" as long as the CIDs are a match.
By the way - I highly recommend to use the buildin editor of WinSCP to make such edits. No need to download any files and so there is no risk to mess up the file format with stupid Windows texteditors.
Ulli

[dan123123]

Thanks for your response.

You have confirmed what i thought, i was just slightly confused because the numbers weren't sequential (why might that be?)

I have edited the vmdk files, started the server up and it seems to be better (the time stamps are a lot closer to what i would expect them to be)

now just waiting on a sql database thats in recovery.

[continuum]

> i was just slightly confused because the numbers weren't sequential (why might that be?)
good snapshot chain:

basedisk.vmdk
parentCID=ffffffff

CID=12345678

snap1.vmdk

parentCID=12345678

CID=2345678a

parent: basedisk.vmdk

snap2.vmdk

parentCID=2345678a

CID=abababab

parent: snap1.vmdk

filenameHints match and CID-values match perfectly.
If you now use the basedisk standalone and start it once the values will change to something that no longer fits the CID-chain like this for example:

basedisk.vmdk

parentCID=fffffffe

CID=bbbbbbbb
On next boot  - this time using the full chain again ESXi notices that the snapshot chain is no longer matching CID-values.
This is done on purpose and you will receive the "parenthasBeenChanged" message and the VM will not start.
Starting the VM after the parent has been changed always does corrupt the filesystem.
This damage is neglectable if you noticed your mistake and immediatly powered off the standalone basedisk.
If you use the basedisk for an extended time or applied many changes the corruption will get larger and larger and may completely damage the filesystem.

snapshot chain after basedisk has been used standalone:

basedisk.vmdk

parentCID=fffffffe

CID=bbbbbbbb  - chain is broken here !

snap1.vmdk

parentCID=12345678

CID=2345678a

parent: basedisk.vmdk

snap2.vmdk

parentCID=2345678a

CID=abababab

parent: snap1.vmdk

[a_p_]

If I understood you correctly, you are confused about the numbers in the file names.

The reason why they may not be ascending is that each time a new snapshot is created, ESXi will use the lowest available number.

Example:

• Create new VM --> virtualdisk.vmdk
• Take Snapshot --> virtualdisk-000001.vmdk -> virtualdisk.vmdk
• Take Snapshot --> virtualdisk-000002.vmdk -> virtualdisk-000001.vmdk -> virtualdisk.vmdk
• Delete first Snapshot --> virtualdisk-000002.vmdk -> virtualdisk.vmdk
• Create Snapshot --> virtualdisk-000001.vmdk -> virtualdisk-000002.vmdk -> virtualdisk.vmdk

André