Wednesday, December 16, 2009

The Parent Virtual Disk has been modified since child was created for VMware Workstation

Few months back I wrote blog about “The Parent Virtual Disk has been modified since child was created” . This blog talks about how we do it on virtual machine which runs from ESX host. One of the user from Norway wrote nice comments about VM running on VMware workstation. I decided to write it as my blog. Thanks Schotterbeck.
HOW TO for Windows and VMware Workstation:

Using this article as a baseline, instead of "grep" use this CMD command: find "CID" "x:\folder\base-file.vmdk"
Use CTRL+C to abort the listing after the first few lines.
Take note of the CID=xxxxxxxx
If not already done so, download and install HEX EDIT FREE (I used v.3.0f)

NOTE: Since the vmdk-files can contain both CID and the whole disk file, they are both fragile AND HUGE! Take special caution when editing these files. A backup copy should always be taken and made write protected!!
This is also the reason why you need a special editor (like HEX edit) to edit the file the right way.

When ready, start hex edit and open the first snapshot file (ex. base-file-000001.vmdk)
Find the "parent=" string in the ascii section of the editor and place the cursor in front of the first letter. Start typing the CID from the base-file.
If prompted, say YES to disable write protection BUT NO to disable Replace mode. This is important to keep the file exactly the way it was, only changing the CID value.

Repeat/Apply this process to other . vmdk files in your chain, if other snapshot files in the middle of the chain has been opened.

Good luck people with all your restores.
And PLEASE VMware, make your programs start doing a check on this, when mounting a new hard drive file! ;)


timm0 said...

I just took a shot at this last night. Went pretty well, but I guess my configuration was a little different and there were some modest step changes needed.

First, I had a couple multi-GB (one is 8GB and another is 12GB) virtual drives which were set up to not exceed 2GB each. I also had a snapshot taken - to complicate things.

So the drive files looked like this:
me@my-laptop:~/vmware/xp-cuz-i-have-to$ ls -hl data*
-rw------- 1 me me 405M 2010-02-20 17:50 data-drive-000001-s001.vmdk
-rw------- 1 me me 61M 2010-02-20 17:50 data-drive-000001-s002.vmdk
-rw------- 1 me me 1.5M 2010-02-20 17:50 data-drive-000001-s003.vmdk
-rw------- 1 me me 320K 2010-02-20 17:50 data-drive-000001-s004.vmdk
-rw------- 1 me me 320K 2010-02-20 17:50 data-drive-000001-s005.vmdk
-rw------- 1 me me 64K 2010-02-20 17:50 data-drive-000001-s006.vmdk
-rw------- 1 me me 528 2010-04-03 20:23 data-drive-000001.vmdk
-rw------- 1 me me 286M 2010-04-04 10:15 data-drive-000003-s001.vmdk
-rw------- 1 me me 6.9M 2010-04-04 10:15 data-drive-000003-s002.vmdk
-rw------- 1 me me 576K 2010-04-04 10:15 data-drive-000003-s003.vmdk
-rw------- 1 me me 320K 2010-04-04 10:15 data-drive-000003-s004.vmdk
-rw------- 1 me me 320K 2010-04-04 10:15 data-drive-000003-s005.vmdk
-rw------- 1 me me 64K 2010-04-04 10:15 data-drive-000003-s006.vmdk
-rw------- 1 me me 535 2010-04-04 09:28 data-drive-000003.vmdk
-rw------- 1 me me 1.6G 2010-03-07 16:24 data-drive-s001.vmdk
-rw------- 1 me me 61M 2010-03-07 16:24 data-drive-s002.vmdk
-rw------- 1 me me 764M 2010-03-07 16:24 data-drive-s003.vmdk
-rw------- 1 me me 320K 2010-03-07 16:24 data-drive-s004.vmdk
-rw------- 1 me me 320K 2010-03-07 16:24 data-drive-s005.vmdk
-rw------- 1 me me 128K 2010-03-07 16:24 data-drive-s006.vmdk
-rw------- 1 me me 647 2010-03-07 16:22 data-drive.vmdk

So for a CID of "aabbccddee" in "data-drive.vmdk", I needed to edit the data-drive-000001.vmdk file's parentCID to be "aabbccddee". For some reason, VMWare WS (6.5.3 build-185404) uses/fills 000001.vmdk and then next uses 000003.vmdk.

The trick I had to use with the data-drive-000003.vmdk file was to tell it that its parentCID is the CID of the data-drive-000001.vmdk file. So if the CID of data-drive-000001.vmdk was "11223344", then the parentCID in the data-drive-000003.vmdk file gets set to "11223344".

Once I got that straightened out, I was back up and running.

Thanks for getting me 95% of the way to fixed! I'd have had to resort to an old backup had this not worked!

Chad said...

What a lifesaver. Got me from a non bootable installation of a critical reporting server. Thank you!

Anonymous said...

Saved me a bunch of effort and grief! Great post, worked as detailed.

irfn said...

Very good post...very detailed...very helpful...thanks Roy

irfn said...

Great post ...very helpful...Thanks Roy