virtualbox.org

Without having tried it yet, it looks like the underlying bug is fixed in v4.0.6, preventing more damage, but of course that will not help with damage already done. Hence, if you only upgrade after the error is seen then the upgrade won't help: xml already zapped.

mpack wrote:Without having tried it yet, it looks like the underlying bug is fixed in v4.0.6, preventing more damage, but of course that will not help with damage already done. Hence, if you only upgrade after the error is seen then the upgrade won't help: xml already zapped.

Are you saying v4.0.4 usage before v4.0.6 upgrade was the problem? If so, then strange that I used v4.0.4 a few weeks ago without any problems. I was basically using it to install the latest MS' Automatic Updates, installing newer v4.0.4 tools (forgot to do that before I saw the v4.0.6) in safe mode (want Direct3D), testing it, making a new snapshot, and deleting the oldest snapshot (don't keep a lot due to tight free disk spaces).

Read this thread carefully, and read the v4.0.6 changelog - no doubt all will become clear.

I just want to say that I've been having this problem repeatedly ever since v3.0
For some reason, VirtualBox will most likely fail to update VirtualBox.xml correctly, and I have to edit the file manually each time it fails to load a VM (usually after I close and open the program again).
And no, it keeps happening even in v4.0.6

hernandes wrote:And no, it keeps happening even in v4.0.6

Then your bug is not the same one being discussed here, the scope of which is well understood. Open a new thread and describe your own problem completely, with pictures, attachments and anything else that may be useful.

After Update from VBox 4.06 to 4.08 on debian sqeeze



The same problem: The VMs concerned (not all have been corrupted), consisting each of two disks and a long chain of associated snapshot.vdi's and .sav's, have been saved before the update. I'd probably better had them closed before ...

The snapshot.vdi's reclaimed to be missing by the GUI, belong each to the last saved set of snapshots.
The VirtualBox.xml itself reflects, that this is a multiattach install connected to 'global' immutable disks, and does not contain any refernce to the snapshots reclaimed.

Removed the entire <AttachedDevice> section for the reclaimed snapshot in the machine.vbox, tried this for one (the reclaimed), and both disks, too.
Alternatively tried, replaced the concerned <AttachedDevice> by the UUID's of a previous snapshot set, and removed the latter in the upper part of the xml.

Refreshed and restarted the GUI. Nothing changed in any case. The VBOX GUI it is always reclaiming the original missing snapshot.vdi (although not being mentioned in the machine.vbox anymore), even after changing the machine.vbox-prev accordingly, too.
No way to come into the settings for the VM by the GUI.

Any idea?


P.S. Sorry, did not recognize this to be a thread for Windows-hosts. Indeed, this error seems to happen more frequently for Win-hosts, rather than for Linux-hosts ... so I hope, it might still be interesting here.

I get the same kind of message, but didn't succeed using the above instructions.
The message reads:

Could not find an open hard disk with UUID {5af3c94c-ea0d-4c13-9613-281df00c6dcf}.
Fehlercode: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
Komponente: VirtualBox
Interface: IVirtualBox {d2de270c-1d4b-4c9e-843f-bbb9b47269ff}

I'm attaching the relevant files to this post. My problem with the above instructions are that there are actually many HardDisks in VirtualBox.xml that I can't find in the Snapshots directory, so I would not know which one I should replace.

Host: Ubuntu 10.10 64bit
Guest: Windows 7 32bit
VirtualBox: 4.0.8 r71778

I would be really thankful for any hints.

@nemec: Well of course the instructions don't work for you, you have an entirely different problem totally unrelated to the OPs bug which existed for a while and was fixed in v4.0.6. You don't have any corruption in any of the xml's you've posted. Your problem is purely and simply that there's a UUID being referenced that isn't in the media registry in VirtualBox.xml. Add it back and you'll bypass that message, though you may then find other files are missing - I have not checked the entire list. So, repeat as required.

A problem of that type would typically be caused by a VBox crash, or switching off the host PC while VBox was running, in between the time a snapshot was created, but before the updated VirtualBox.xml file was saved.

Incidentally: your VM has IMHO grown to a humungous mess of ridiculous proportions. I'm amazed you are prepared to tolerate the waste of all that disk space on old snapshots. It is also a lot of eggs to keep in one basket: I suggest that you use CloneVDI or VBoxManage to take a merged clone of the latest VDI state file, which you can put aside as a backup. Don't attempt to delete any snapshots while the snapshot chain is suspect, as it is now.

Yup, This fix totally worked for me. Thanks!

ant wrote:Weird. I had problems too! I tried to open an old Windows XP Pro. SP3 VM that I was just using before upgrading VirtualBox v4.0.4 to v4.0.6 in my old Debian box (installed in 2005). I got this.

Failed to open virtual machine located in /extra/VirtualBox/Machines/XP Pro. SP3/XP Pro. SP3.xml.
Could not find an open hard disk with UUID {7bca213c-b890-47ed-a820-ddc8988ec94c}.

Result Code:
VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
Component:
VirtualBox
Interface:
IVirtualBox {d2de270c-1d4b-4c9e-843f-bbb9b47269ff}


I tried editing my /extra/VirtualBox/Machines/XP Pro. SP3/XP Pro. SP3.xml file, readd the two snapshots/.vdi files. It worked.

It again after upgrading to v4.0.8, upgrading its tools in safe mode, and then deleting the oldest snapshot. I did notice it never showed it deleting my old snapshot. Since this image is years old and probably will happen again after I do manual fixes, I am just going to install a new slipstreamed XP Pro. SP3 image from scratch.

I have this problem with VB v4.1.0 and Solaris 11 Express as host. I am using immutable disks and differencing disks to only store changes.

As root, when I try to create a new differencing disk based on WinXP, it works well. As root, when I try to create a new differencing disk based on Win7, I get this error.

I am using "root" account because I need access to a NTFS partition which I can read via VB. This NTFS access can only be done as root.

To the immutable disk I have connected several differencing disks, so I dont dare to edit some files in the immutable disk. Maybe all the differencing disks will stop to function? Is there any other fix? I can edit a differencing disk, but I dont dare to edit the base immutable disk.


WORKAROUND: I just installed the entire VM to "root". So root does not use any immutable disks nor differencing disks. And this works. But I would prefer that root also could use differencing disks based on the immutable vdi.

Just in case people are looking for the answer.

Perhaps you like me needed to either move virtual machines especially while creating templates or just getting your storage organized .. here is the short of a long.

Perhaps you ran the command :
vboxmanage internalcommands sethduuid "<full path to VHD>" Maybe you did something else who knows and might not make a difference for you.
And from there you were expecting good things.

I ran a little friend of mine called Agent Ransack - I highly recommend that gem. It scoured the internals of every file on my hard drive for the UUID - I found the file that it was contained in - my .vbox file of all things ( I had been looking before but I was looking only at hard disk uuid.. so what was up - and my hard disk uuid did not match that uuid..
So I searched the file for the text and came to an entry at the bottom of the file, The HardDisk storage tag - so this uuid did not match my hard disk uuid ; my assumption was that they should match. In order to verify this I checked out some working vm's and it was as I had guessed - I changed the image uuid to match my hard disk uuid .. and all things worked again.

In order to MANUALLY edit the .vbox file -your VirtualBox and any other applications VboxSvc etc need to be Killed, not running...

Here are the components from the .vbox configuration file , just in case a nice picture is cooler than hey that thingy in a file somewhere ....

"As a disclaimer : All uuid's listed below have been changed in order to protect the innocent." [You have to admit that was funny].
BTW: You will love my corny humor when your VM is kicking it again..

This topic discusses a bug which was fixed 8 years ago. Locking it.