[Solved] A differencing image of snapshot could not be found

[Karen]

Ugh.....I made a "snapshot" for the very first time on my virtual box (Windows 7 32 bit hosting a Windows XP machine)...then all heck broke loose.

My Windows 7 machine was rebooted after updates over the weekend and now my virtual machine will not boot up...here's the complete error:

The selected virtual machine is inaccessible. Please inspect the error message shown below and press the REFRESH button....

A differencing image of snapshot {ad844edc-5e41-40d7-b83d-23605d45695f} could not be found. Could not find an open hard disk with UUID {f9043635-08c4-47f8-8395-86e4ebbf1ab0}.
Result Code:
E_FAIL (0x80004005)
Component:
SnapshotMachine
Interface:
IMachine {22781af3-1c96-4126-9edf-67a020e0e858}


I have tried several things based on the threads like trying to add UUID of the snapshot in the XML....I don't know if that was right.
What a mess ....if that feature doesn't work, why have it there?

I need to get this back up pronto!!! Can anyone give me step by step instructions so I don't lose my existing setup? I do see the "hard drive" if I go to create a NEW virtual machine and choose an "existing" hard drive....but it not showing under Virtual media manager, and everything is grayed out...except REFRESH.

(user in panic mode)

[mpack]

This error can't really be diagnosed remotely - you need to do some more digging.

Use CloneVDI to look at the base VDI. Use the "Header Info..." feature and make a note of the "UUID (create)" field.

Go through all VDI files in the Snapshots subfolder. Examine each of them with CloneVDI, noting their "UUID(create)" and "UUID(parent)" fields.

Put your notes in a text file, and attach it in a zip here - and include a copy of the VMs .vbox file as well.


p.s. Snapshots are avoided by most experienced users. They are too dangerous and serve almost no useful purpose (newbies only think they serve a purpose).

[Karen]

Thank you mpack for helping.....will CLONEVDI work with .vmdk files?

Karen

[mpack]

CloneVDI will work with VMDK to the extent of being able to clone them (creating VDI format clones), but I rarely use VMDK so can't remember what info is given in the header.

One thought - if you only just created the snapshot then it contains nothing of importance, is that correct? If so, then you could simply clone the base VMDK (using VBoxManage or CloneVDI as you prefer), then build a new VM around the clone.

I do recommend using the VDI hd format in VirtualBox - as the native format it's the only one that's guaranteed to support all VirtualBox features. If at a future date you need them in VMDK format then you can convert the format at that time using VBoxManage.

[Karen]

One thought - if you only just created the snapshot then it contains nothing of importance, is that correct? If so, then you could simply clone the base VMDK (using VBoxManage or CloneVDI as you prefer), then build a new VM around the clone.

That is correct....
How do I do this? I'm sorry....this whole setup was done years ago by someone else. I just maintain the software inside that needs to still run on XP
So I have limited knowledge on using these tools..........
Can you clone to another drive instead of the path I'm on....running out of space on C drive now

[Karen]

Here is my zip file....

[Karen]

Try to run your CLONE VDI (hitting the proceed button) after changing the destination path to F drive. F drive is a USB 500 gb hard drive.
I had "Generate new UUID" checked ....no other options

I made all folders identical on F drive as they were listed on the source drive --- so it matches in path name except for the drive letter.

It get to 14% and comes back with DRIVE WRITE ERROR...

Karen

[mpack]

Looks like a real mess in your zip. I would suggest following these steps:

1. Identify the most recent snapshot and clone it with CloneVDI. This will produce a merged (flat) disk in VDI format. Tick the "Compact" checkbox in CloneVDI to minimize the clone size. You can specify a different destination path.
2. Rename the clone VDI to something more meaningful.
3. Create a new VM with 512MB RAM and 32MB VRAM. When you get to the disk creation step, select "Use existing" and browse to and select the VDI.

The VDI should ideally reside inside the VM folder: I suggest moving it in there just before browsing to it as in step 3 above. Don't worry too much about disk space - as soon as the new VM is tested as working, you can delete the old VM. Of course it wouldn't hurt to make a backup of the VM folder before doing any of this.

[mpack]

It get to 14% and comes back with DRIVE WRITE ERROR...

F: is a removable drive, right? The most common mistake is that it's FAT formatted, and hence can't store files larger than 4GB. 4GB was unthinkably large for a drive when FAT was invented. To have a single file that size, well you'd be laughed off the podium... Of course 4GB is nothing unusual for a VDI file.

[Karen]

Okay I tried to clone the snapshot which is a vmdk file to a destination .vdi file with compact ticked and generate new UUID ticked

ERROR

Source is a different image....sorry this tool can not clone these (for now)

[mpack]

Then try another of the snapshots (if it exists), and finally the base VMDK.

And be aware that compaction may not be enough to ensure that the clone VDI is smaller than 4GB. The only real way to avoid this problem is to output to a drive with a modern filesystem on it. I use NTFS on some of my flash drives for this very reason. However you then have to be careful to eject the drive properly before unplugging it. In fact I never use the drive while it's located on removable storage - that's just begging for it to be corrupted.

[Karen]

I only had the one snapshot....the one that killed everything....

I will try the base vmdk then...do I still use Generate new UUID and Compact drive with copying (on my C drive)?

[mpack]

Yes.

[Karen]

How much shrinking does the ticking the "Compact" do? I'm trying to make space for the cloned drive

[mpack]

That can't be predicted from here. Compaction discards the space used by deleted files, so the clone will be somewhere around the same size as the "Used" space reported by the guest OS. As I alluded earlier, compaction minimizes the space needed by the guest, it doesn't guarantee that it will shrink as such at all.