Urgent help: Parent disk modified since child was created--RC1. What to do?

[tirmidi]

Well, I was experiencing extremely poor performance with my XP SP2 virtual machine. So I decided to create a new virtual machine using the original drive image that I had been using since the first beta. In the process, I was asked if I wanted to use the updated disk format; this time (unlike the previous installation) I agreed to do so.

The newly created machine worked much better (much lower CPU usage, single CPU, etc). However, I had not understood that there was a "child" drive in the Virtual Machines folder, somehow linked to the original hard drive image, and it is this child that contained my latest changes and data. Hence, I lost my most recent changes with the new machine.

Aha, I thought, I'll simply create yet another virtual machine, but point it to the child hard drive image in the older VM Virtual Machines folder. But that did not work, as I got the message shown in the title.

Moreover, when I tried to run the older VM, I ran into the same problem--the "child" isn't any longer compatible with the parent, and the VM refuses to boot.

What can I do, if anything? Can I manually update the child image so it will work with the updated "parent"? Can I specify the older "child" as a second hard drive in the new VM and bring over the data?

Or am I altogether up the creek?

[admin]

Hi Oliver and everyone,

Keep in mind this isn't a misdetected CID mismatch (due to pathname bug or anything else) -- the parent disk really was modified since the child was created (exactly what the error says) and it really is no longer provably valid to attach the child to the parent.

I know you're trying to recover your data and everyone's trying to help and that's great, but just to set expectations, at this point it's possible that disk corruption will occur (the parent disk is still fine but contains only what it contains, i.e. what you saw in the second VM; the child disk is internally intact but to really use it it needs to reference a parent which no longer exactly exists; if you proceed to force the child to attach to the somewhat-modified parent, Windows may think the disk is corrupt).

[admin]

For reference for others:

So I decided to create a new virtual machine using the original drive image that I had been

using since the first beta.

...

However, I had not understood that there was a "child" drive in the Virtual Machines folder,

somehow linked to the original hard drive image, and it is this child that contained my latest

changes and data.

This means your original VM had a snapshot, so only the snapshot was stored in the original hard drive image, and all changes since the snapshot were stored in a separate hard drive image (the child disk).

It's too bad that we can't detect if you take a disk that's part of a snapshot and use it directly (once a disk is part of a snapshot, i.e. has children, it should never be modified directly; anything that wants to use it should create a new child, and reference the snapshot disk only as a parent).

So anyone creating a VM from the disks used by an existing VM, if the existing VM has a snapshot, you need to point the new VM at the child disk, not the parent disk.

[tirmidi]

So anyone creating a VM from the disks used by an

existing VM, if the existing VM has a snapshot, you

need to point the new VM at the child disk, not the

parent disk.

Well, gentlemen, I am back in business. Inspired by Magi's comments, I created a new VM, and pointed it to the child disk whose CID's I edited in accordance with the instructions offered above. I did not try to reuse the old VM with its dual disk set up, figuring (correctly) that I could edit the new vmx later.

It booted without a problem (although Windows apparently had to perform a small repair to the registry), has low CPU usage, and I can now access my changes and data.

Thank you all for holding my hand through the process.

Message was edited by:

tirmidi

[tirmidi]

Here is a brief account of how I got my VM rebuilt.

1) I opened the parent disk with Apple's hex editor 0xED (available for free download).

2) I determined the CID of that parent

3) I opened the child disk with the editor, and changed the parentCID to that of the CID of the parent. NOTE: There are three instances in the file that reference the parentCID, and I changed all of them, using the search function

4) I saved the child to the Virtual Machines directory in ~Documents, locating it outside the existing VM packages.

4) I created a new VM, and pointed it to the newly edited child drive.

5) As the fiddler players say, "Viola!"

[oreeh]

Keep in mind this isn't a misdetected CID mismatch (due to pathname bug or anything else) -- the parent disk really was modified since the child was created

I'm aware of that

I know you're trying to recover your data and everyone's trying to help and that's great, but just to set expectations, at this point it's possible that disk corruption will occur

I'm aware of that too

With WS/Player/Server I (and Ulli / continuum) had good results with this procedure.

I admit this is a bit easier with Windows hosts since there you can use VDK to mount the disk read-only and copy the data off of it instead of having to start the whole VM.

[tirmidi]

Update:

As Magi predicted, it appears that the drive was somewhat corrupted. The good news is that having run chckdsk, all seems well. However, I am going to archive my changes and create a brand new VM from the parent.

Question: how do you delete entries from the VM list?

[nathanp · Accepted solution]

To just remove the listing of the VM from "Virtual Machine Library", select the VM and press 'delete'.

This will only remove it from the list and not delete it from your system.

[tirmidi]

To just remove the listing of the VM from "Virtual

Machine Library", select the VM and press 'delete'.

This will only remove it from the list and not delete

it from your system.

Works like a charm. Why didn't I think of that?

[tirmidi]

After successfully reconciling the parentCID with that of the child so my VM would run, I began to experience much degraded performance of several applications. At the end of this cycle, my crucial Outlook .pst file became corrupted, beyond the point where the inbox repair tool could fix it, and I had to purchase a repair utility, which worked like a charm. However, I concluded that the disk errors that had crept in because of the real discrepancy between parent and child were too serous for Windows to repair.

Luckily, the modified VM ran sufficiently well that I could save the changed files to my shared folder; then I created a new VM from the parent.

The difference is spectacular. The VM is much more responsive, all applications work correctly, and the resource utilization is way way down. Now the resting level, with a bunch of applications active simultaneously, is only around 12% of the CPU.

The moral of the story is that the disk editing method should be reserved for emergencies; the result will probably be unstable.