vm inaccessible suddenly

[pitters]

Hi all,
I have Win 7 host and Win XP as guest on Fuji 64-bit 8GB RAM
I saved my VM last night, then put the laptop to Sleep.
This am I had to restart (Windows Update) and now my VirtualBox Manager shows all 3 VMs as inaccessible.
The error message details are:
"A differencing image of snapshot {d29074ca-6470-4b79-8c70-9e7bdaa68fb3} could not be found. Could not find an open hard disk with UUID {17a6c504-5976-421e-851e-f485c2422dc7}.
Result Code:
E_FAIL (0x80004005)
Component:
SnapshotMachine
Interface:
IMachine {22781af3-1c96-4126-9edf-67a020e0e858}"

I'm not a techie - looked at the end of the log (attached) and see that something apparently DESTROYED my work

If anyone (mpack?) can help, would be most appreciated
pitters

[pitters]

Sorry, forgot to mention I'm using VM 4.2.12r

pitters

[mpack]

If it affected one VM then I might guess that the <vm>.vbox file had been corrupted. However, for this to happen simultaneously to three VMs is very odd. Does the error message give the same UUID value in all three cases? If yes then it means they share the same disk, and something has happened to that disk.

What connects these VMs? Are you using linked clones? If so, then it looks like you have have deleted the base VM that they are all linked to, which would be a fatal mistake if you don't have a backup. Another possibility is that you forced these VMs into sharing a base disk somehow, making them interdependant, and for some reason that base disk is no longer registered.

If you want more help then please provide a .zip file containing the VirtualBox.xml file, plus the .vbox file from a VM. A screenshot showing the same VMs folder contents would be good too.


ps. The mention of "Destroy" at the end of the log is normal, not sinister. That log is from your last working session, and the end of which the running program was terminated / killed / destroyed - whatever you want to call it. The log doesn't actually show anything wrong, because the log tells you about a running VM, whereas in your case its the VBox front end which has a problem getting together the stuff it needs to even launch the VM.

[pitters]

Hi mpack,
Thanks for such a speedy reply . . . do you live online?
Here are the files:

VirtualBox.xml

(3.12 KiB) Downloaded 7 times

Crash XP.zip

(5.4 KiB) Downloaded 3 times

Crash.zip

(264.91 KiB) Downloaded 3 times

The last one contains the 3 snapshots of VM's error message on each.

I had to rebuild my VM only last week when I deleted the wrong (!) file 'cos of lack of space
(Do I have to make my confession in public? Oh well, such is the price of stupidity!)
Maybe I was too cynical in naming the VM Crash???

I was trying to link to various versions of old VMs to get back to a working copy - hence the 3 vms.
But I have only been using the first one Crash XP for the last week.

Regards
pitters

[mpack]

I spend an hour or so each morning with my first coffee catching up here. You were lucky to ask your question within that hour. Later in the day answers may come slower.

The xml is a spaghetti mess with the VM referencing two disks each with a hierarchy of snapshots attached. In "Crash XP.vbox", one of the older snapshots references a disk with UUID "{17a6c504-5976-421e-851e-f485c2422dc7}", but this UUID does not appear in the media registry of the VM. You didn't provide that folder listing I asked for, however I've made a guess as to the location of this file and manually added it to the registry. See modified "Crash XP.vbox" file attached. Back up your old file and give this a try.

I recommend that you abandon snapshots asap. The easiest way to do that is to do a full clone of the VM once you get it running.

[pitters]

Sorry, mpack, I'm not sure what listing you wanted.
Is it any of these 3 snaps?

Vbox folder.zip

(377.23 KiB) Downloaded 3 times

You suggested " See modified "Crash XP.vbox" file attached. Back up your old file and give this a try."
I tried renaming it to Crash XP.vbox-old and extracted yours (see

Vbox folder.zip

(377.23 KiB) Downloaded 3 times

)
but to no avail.
The VM still comes up with the Inaccessible messages.

Guess I'll have to set up a new one and start all over again?

Thanks for your help

Regards
pitters

[mpack]

I was looking for a listing of the folder where the VM is looking to find its media files. In the case of this VM, that's the VM folder (which contains the .vbox file) and for your case I particularly need the Snapshots subfolder.

Lets also take one VM at a time, otherwise it gets confusing.

If you replaced the .vbox file with my modified version then the error message should have at least changed. Look in the snapshots subfolder for a file with the name "{17a6c504-5976-421e-851e-f485c2422dc7}.vdi", make sure it is present there.

[pitters]

Hi mpac

Here's the snapshots and the VM error - cannot see a change - or the snapshot you mention

VM error message.zip

(167.18 KiB) Downloaded 2 times

You're saying I should just clone instead of taking snapshots?
I looked at your CloneVDI discussion - have read some of it before, last year.
I thought I might as well start at page 57 and work backwards through the 842 posts (!)
but is there a shorter description in a different place?

Regards
pitters

[mpack]

Well, it's clearly now complaining about a different UUID, so the error message has changed. However this means that you have multiple missing snapshot files, which isn't very encouraging to say the least.

Another thing you can try is to to find every VDI related to this VM (or better yet the original VM from before your crash), put all the files into one folder and then see which of them CloneVDI will agree to clone (it "agree" when it finds a complete chain with no missing files). Try to the clone the {xxxx}.vdi file with the most recent creation date. If you succeed then you'll have a standalone VDI which you can build a new VM around. Note that it must be a new VM - if you try to mount the clone VDI in your existing VM then you'll just make things worse. The idea is to start with a blank sheet, build a VM you're happy with, then delete all that old snapshot stuff.

Yes, in future if you want to secure the current state of a VM, I suggest you make a backup. Recovering your situation from a backup would have been trivial. Snapshots make it a nightmare.