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

Now I know this is an old one dating way back but just wanted to add this as a note on my blog here. If you can use it great... I will start by telling a story:

So today my colleague decided to move one of his test servers from a ESX Foundation box to our ESX cluster. The mistake he made was he did not remove the snapshots before he moved the guest to the cluster. Also he had already deleted the original server from the ESX Foundation box, easiest fix ruled out. He contacted me for help when he received the message trying to boot the server:

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

Easy fix here, But backups must be taken of everything for safety sake. This is the VMDK from the actual base disk (see below). Now this is a simple one because it had one base disk and one delta file. It would be easiest just to change the VMX file to point to the base disk VMDK but problem here is the snapshot had all the necessary apps loaded it into it and the base disk was a plain installation.


# Disk DescriptorFile
version=1
CID=fc9c727e
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 25165824 VMFS "flapjacks-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "1566"
ddb.uuid = "60 00 C2 9d ee 19 a7 ba-71 16 1c ac cc 2b 2b 09"
ddb.toolsVersion = "7202"
ddb.virtualHWVersion = "4"


See the CID above? Check the VMDK of the Snapshot and I bet you money it doesn't match the parentCID. Simply change the parentCID value to match the one on the base disk and the server should now boot. By forcing the CIDs to match it should think it is was never out of sync.

We had another problem. The old snapshot could not be deleted/merged because something still was not quite right. So I did a v2v with converter to a new guest and was able to merge things that way. Now I know this is probably not a perfect situation but the new server is running stable now so I will take it!

If this was a more complex situation and more changes had been made before the server was moved the data should have simply been recovered after getting it to boot and the server reloaded because chances are in that situation it would not be very stable.