virtualbox.org

Hello,

A VM has become inaccessible after a sequence of actions (presented below). I appreciate any help in getting the VM back online.

Environment:

• Host is an AMD64 machine running CentOS5 with VirtualBox 3.2.10 initially (note that we update to 3.2.12 in the process below).
  
  Client is also running CentOS5.

The VM needed resizing of its root file system (increase size). Therefore, the following sequence was followed, leading to the problem:

1.1 Shut down VM
1.2 Took a snapshot
1.3 Added a SATA controller
1.4 Created a 2GB virtual disk
1.5 Attach disk to SATA controller
1.6 Start VM
1.7 Resize LogVol00 (LVM is in use) and root (/) file-system (ext3) on running system

Here the system seemed to accept the change on-the-fly. FS usage dropped to 77% from 90%. We started using the system (which hosts code repository using Mercurial) with no problems. The next day:

1.8 Reboot VM

At this point we realized Step 1.7 broke the system, which would fail to read the FS on boot. Apparently, resizing on-the-fly is not an option. Therefore:

2.1 We go back to snapshot from step (1.2)
2.2 We perform some maintenance (basically have developers push some code changes from their locally-cloned repositories that were lost from the main repository)
2.3 Take a new snapshot to use as a base-line.
2.4 Shut down the VM
2.5 Attach a "system rescue CD" after to IDE secondary master

At this point, we got an error that the VM cannot be modified (E_NOACCESSDENIED). Strangely, when we started the VM in the next step, the change appeared to have been applied:

2.6 Start VM (system rescue CD was found and used in spite of error above)
2.7 Resize root (/) FS (ext3) while not mounted
2.8 Stop VM
2.9 Start VM

At this point, we saw that the VM would start, the root FS was increased (77% free instead of 90%) and all the data we added in step 2.2 was still there. So, we decide to clean up:

3.1 Stop VM
3.2 Delete snapshot 1.2 (took a long time)
3.3 Delete snapshot another, older snapshot (not taken during the above steps -- this took even longer due to a merge)
3.4 Start VM

Now, we got the same E_NOACCESSDENIED error we got in step 2.5 above. Only the VM would not power-on at all.

Unable to start the VM, we upgrade to VirtualBox 3.2.12 to see if it helps. Now when we open the GUI we see the VM with a status of "Inaccessible" and the following text in Details:

A differencing image of snapshot {88f0398a-d5cd-4bc7-89a9-03838acb0b2a} could not be found. Could not find a hard disk with UUID {99c85c6d-56a1-41b3-b18f-971e333fc2c2} in the media registry ('/data/vbox/.VirtualBox/VirtualBox.xml').

Since our data seems to be intact (remember after 2.9 all the data was there) we want to salvage the system. No snapshot deletion / merging was interrupted and everything was completed successfully, so the system should be relatively ok.

Can anyone suggest how to proceed?

Ok, I have located the <Snapshot> that references the disk UUID that is missing. I deleted the relevant <Snapshot> tag (and its nested snapshots) and refreshed the VM state. Now the VM is accessible. Basically,it appears as if VirtualBox got confused by the deletion of 2 parallel snapshots using a common root and left one of the nested snapshots in the XML.

I've booted into the VM using the rescue CD and the data indeed seems to be there (the LogVol00 size is increased, browsing the FS to the most recent Mercurial commits done in step 2.9 seem to be there.

I am doing some sanity checks and will reboot the machine from disk. Hopefully, VirtualBox corrupted the XML but treated the disks correctly...

System is back to normal.

So far, it seems that VirtualBox simply updated the XML incorrectly, but merged the differencing images correctly. All recent data changes we checked are in place.

Hi akarypid, thanks for having shared your solution, I've had the same problem after my VM crashed during a merge of two snapshots, the VM is now unaccessible and I've got the same error message.
Can you please give me details about how to edit the .vbox XML file to use an older snapshot?
Many thanks,
Julien

Had the same error, but what I did wrong was that I actually chose the wrong .vdi image... I tried Machines/Win7/Snapshots/{39f92581-05f5-46b2-93ad-68e2ab9a7281}.vdi but it turns out I need to use VDI/Win7.vdi... OK, that's pretty obvious, but maybe someone else's been stuck at the same point out of clumsiness, so nevermind if this doesn't help.

Hi, this is my first post on this forum. I read the posts above, which helped me with the similar problems I had after merging two snapshots in the GUI.

The problem was as previously posted, that the VM was inaccessible, and a VBoxManage showvminfo <uuid> showed:

VBoxManage showvminfo 06260a0d-bfca-4c91-946f-f86e5a369322
Name: <inaccessible!>
UUID: 06260a0d-bfca-4c91-946f-f86e5a369322
Config file: /root/VirtualBox VMs/SLES 10 SP4/SLES 10 SP4.vbox
Access error details:
VBoxManage: error: A differencing image of snapshot {fb250a34-0fed-4a41-b179-d94c318c2226} could not be found. Could not find an open hard disk with UUID {63dc8422-5152-44f3-9779-a9bbfc4c8fda}
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component SnapshotMachine, interface IMachine, callee



The solution was to open the Config file (SLES 10 SP4.vbox as stated above) with my favorite editor (I use vi), and simply search for the UUID for the open hard disk that is mentioned in the error message. When you find it, you replace it with the correct UUID, which you should either find in the beginning of the config file:

<?xml version="1.0"?>
<!--
** DO NOT EDIT THIS FILE.
** If you make changes to this file while any VirtualBox related application
** is running, your changes will be overwritten later, without taking effect.
** Use VBoxManage or the VirtualBox Manager GUI to make changes.
-->
<VirtualBox xmlns="....">
<Machine uuid="{06260a0d-bfca-4c91-946f-f86e5a369322}" name="SLES 10 SP4" OSType="Linux" currentSnapshot="{fb250a34-0fed-4a41-b179-d94c318c2226}" snapshotFolder="/home/mikael/vm" lastStateChange="2011-12-06T23:47:41Z" aborted="true">
<MediaRegistry>
<HardDisks>
<HardDisk uuid="{f9bb8c26-45fe-43ea-93cb-65c2e70c5ba1}" location="/home/mikael/vm/sles10.vdi" format="VDI" type="Normal">
<HardDisk uuid="{92dc4134-374c-472d-8e11-c872826cf7fd}" location="/home/mikael/vm/{92dc4134-374c-472d-8e11-c872826cf7fd}.vdi" format="VDI"/>
</HardDisk>
</HardDisks>


The first HardDisk shows the "base disk" and the second shows the current "snapshot disk".

After this fix (took less than a couple of minutes) the VM runs as normal again!

I do not guarantee this will work for you, and I would strongly recommend making a backup of the xml file before editing it.

Hope this has helped somebody!

great solution mickemic
everything works fine
thanks

It seems virtualbox automatically backs up your file to a .prev extension. I had the same problem with the "child drive" missing and I was able to go to my "VirtualBox VMs" directory and do...

shutdown all virtualbox processes
$ mv fedoravm.vbox fedoravm.vbox-bad

$ cp -p gil-fedoravm.vbox-prev ./gil-fedoravm.vbox

I am glad this worked because I would have had no clue what uuid's to substitute for which in the xml file. Whew!

It seems my snapshot history is intact (I have a lot of snapshots!) and my vm looks normal and current.

By the way, this happened to me after virtualbox locked up when I was trying to add a USB drive to the vm. It locked up hard and my vm stopped running. I ended up having to kill vbox processes and reboot.

I am thinking that I may start backing up these files so I can revert to a previous date if I have to.

Also, before I do any reconfiguration or messing with snapshots, I plan to make sure I have backups of the xml files.

Renaming the "-prev" file may sometimes make things worse rather than better.

Performing any snapshot operation will involve processing the chain of snapshot VDI files, and then updating the control information (in the .vbox file) to match. The "-prev" file will be created when the updated control info had been written (as a "vbox-new" or "vbox-tmp") and now needs to be renamed to ".vbox".

To cut the story short, if you rename "vbox-prev" to "vbox" then you may have a situation where outdated control information is describing the new snapshot chain, and that could cause serious problems.

Any problem of the type discussed in the thread above must be solved by understanding the specific situation and applying a specific fix. Generic magic bullets are not going to work, unless it is "restore from my recent backup".