Tuesday, April 7, 2009

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

We came across many instance when we have expanded the HDD which has snapshot and when we try to power on we get error “The parent virtual disk has been modified since the child was created” One
of my former college and guru’s has
blogged about it . I found nice KB 1007849 which I thought of copying because
of fear that I may loose the track.

This error can occur under the following circumstances:

  • The base disk of thevirtual machine has been changed

  • Running out of space on the LUN that contains the snapshot

  • Virtual machine suffers a blue screen exception when a snapshot is taken

For more details about snapshots and missing header files, see Cannot power on a virtual machine because the virtual disk cannot be opened (1004232)

Before implementing the solution, ensure:

  • You know the file names of all virtual disks associated with the virtual machine. Use the following command and record the output:
    #grep -i filename /vmfs/volumes/old_datastore/vmdir/*.vmx | grep -i

  • That there is enough space on the target datastore to receive the cloned virtual disks. Use the following command to assess how much space is needed:
    #ls -lah /vmfs/volumes/old_datastore/vmdir/*flat.vmdk

    Note: This example assumes that all of the virtual disks are contained in the directory with the virtual machine configuration file (

  • A complete snapshot chain with matching CIDs and Parent CIDs (obtained from step 2 in the procedure).

  • The virtual machine is in a powered off state.

  • There is enough time to commit the snapshots. This procedure can take an extended amount of
    time depending on the size of the delta files.

To match the CID of the snapshot to the base disk:

  1. Find out what disks the virtual machine is using. Log in to the ESX host and navigate to the directory that contains the virtual machine. Run the following command to identify which virtual disk files are being

    # grep -i filename *.vmx

    The output appears similar to:
    scsi0:0.fileName = "vm-000002.vmdk"
    scsi0:1.fileName = "vm_1-000002.vmdk"
    This virtual machine has two virtual disks.

  2. Check the CID of the base disks and compare them to the snapshots to see if they match.Run the following command to obtain the information about the virtual disk:
    #cat vm_1-000002.vmdk

    Theoutput appears similar to:
    This indicates that the file vm_1-000001.vmdk has the CID of 20d215cd.
    Do this for each file in the snapshot chain until you get to the base disk.

  3. Clone the virtual disk to a new base disk. To clone the virtual disk:

    1. Run the vmkfstools -i command to copy out and consolidate the snapshots. This requires enough space for the basedisk. The command ls -l *-flat.vmdk gives the size of
      each base disk in the current directory.

    2. Create a directory on a the target datastore if you are not cloning to the current directory:
      #mkdir /vmfs/volumes/new_datastore/recover

    3. Run the vmkfstools -i command to clone out the last vmdk delta disk pointer VMDK:
      #vmkfstools -i /vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk

      The output appears similar to:
      Destination disk format: VMFS thick
      Cloning disk '/vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk'...
      Clone:100% done.

      Note:If the above process does not work, choose the next snapshot up the tree as the one you are on (or one of the higher ones) is corrupt.

    4. Detach the disk from the virtual machine using the VI Client.

    5. Attach the new disk, /vmfs/volumes/new_datastore/recover/vm-disk2.vmdk
      to the virtual machine.

    6. Power up the virtual machine and ensure data integrity (Event Viewer, SQL, E-mail, etc).

  4. Delete the base disk and only it's snapshot disks.
    #grep -A2 parentFile vm_1-000002.vmdk | grep -v "#"

    Theoutput appears similar to:

    RW 41943040 VMFSSPARSE "vm_1-000002-delta.vmdk"

    This indicates that the pointer vm_1-000002.vmdk points to vm_1-000002-delta.vmdk and is using vm_1-000001.vmdk as it's parent disk.
    You may run the same command on the parent pointer to determine what files it uses, until you locate them all.
    #rm /vmfs/volumes/old_datastore/vmdir/vm_1-000002.vmdk
    # rm/vmfs/volumes/old_datastore/vmdir/vm_1-000002-delta.vmdk
    #rm /vmfs/volumes/old_datastore/vmdir/vm_1-000001.vmdk
    # rm /vmfs/volumes/old_datastore/vmdir/vm_1-000001-delta.vmdk
    #rm /vmfs/volumes/old_datastore/vmdir/vm_1.vmdk
    # rm /vmfs/volumes/old_datastore/vmdir/vm_1-flat.vmdk

    Note:If you are going to use rm with a wildcard, echo the command first.This allows you to see which files are being targeted for erase.

    #echo rm *.vmdk

  5. Move the VMDKs back to the original location and re-associate the virtual machine with the new disks.
    To move the VMDKs back to the original location:

    1. Run the following command to clone the disk back to the original data store.

      #vmkfstools -i /vmfs/volumes/new_datastore/recover/vm_1.vmdk/vmfs/volumes/old_datastore/vmdir/vm_1.vmdk

    2. Detach the recovered disk from the virtual machine using the VI Client

    3. Attach the new disk in the original location, /vmfs/volumes/old_datastore/vmdir/vm-disk2.vmdkto the virtual machine.

    4. Power up the virtual machine and ensure data integrity (Event Viewer, SQL, E-mail, etc).

  6. Clean up the snapshot database.Rename the .vmsd file, remove the virtual machine from inventory, and re-add the virtual machine to clear the snapshot database.
    #mv vm.vmsd vm.oldvmsd


Anonymous said...

where are you typing these commands? linux shell?

i am in windows vista with a vmware of windows xp pro that can load the flat (base) disk however all of the applications installed (i.e. 4GBs) are no longer present. I have a snapshot and a WinXP-000001.vmdk. Trying to boot into the 000001 however get the error you described on your blog.. any ideas?


Øystein Schlotterbeck said...

HOW TO for Windows and VMware Workstation:

Using this article as a baseline, instead og "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 proses 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 harddrive file! ;)

Øystein Schlotterbeck