Inaccessible ('Nicht zugreifbar') / 0x80BB0001

[mpack]

In that case it seems likely that my problem is unrelated, since I haven't deleted any snapshots in quite some time. Thanks for the info (good to have it in the thread also, since googling the error got me here). I'll see if I can muddle through patching the xml.

I've now looked at your xmls, and whatever the cause, your symptoms seems to be identical to the OPs - hard disk with a certain UUID is gone from the media registry (having checked both VirtualBox.xml and the VM settings xml), but that UUID still referenced by the outermost (snapshot base) AttachedDevice section. The cure is the same as the OPs as well: delete the last hard disk AttachedDevice statement in the file, in your case delete lines 662-664 of the BasicUbuntuInstall.xml file.

Incidentally, did you rename the latter file? I expect it to have a .vbox extension if it comes from a v4 system.

I also find it interesting that your media registry contains prominent mention of VMDK files, just like the OPs. Do you do anything at all of significance to this VM recently? I'm thinking export, import, backup using "VBoxManage clonehd" etc - anything major involving virtual disks and that VM?

[mpack]

Actually, I'll take back a chunk of what I just said, because in retrospect I don't have a handle on this problem at all. But, let's see if I can clarify it here and now...

The facts seem to be these:

• The error message always complains that a disk with UUID {0123.uuid.example.only} does not exist in the registry.
• It is perfectly correct, i.e. the disk does not appear in the registry.
• The error can happen regardless of whether the media registry is global(legacy), or local to that VM, or a mix of both.
• It only affects VMs in which snapshots have been used.
• On examination of the settings xml you find that the bad media reference is in the AttachedDevice section of the outermost scope of that xml.
• Strangely, while the referenced UUID in the oldest xml scope should I think reference the oldest virtual HD, in fact you can usually see something named suspiciously like the oldest virtual HD is still present in the media registry, but it has a different UUID.

Two possibilities then: one is that something is patching the AttachedDevice section of the outermost xml scope with the wrong UUID. The other possibility is that something is changing the UUID of the base virtual HD in a snapshot hierarchy.

I lean towards the former as the most likely bug: i.e. something, for some reason (and there may be several) is modifying the UUID reference in the AttachedDevice section in the outermost settings xml scope without taking into account the possibility that snapshots may be present, which would mean that it was the innermost scope which should have been modified.

Now, note that the AttachedDevice section of the outermost scope is not actually needed unless you revert/restore to that point in time - so it's possible that only the error message is new. I.e. possible that the damage was done some time ago, and v4 just has enhanced error checking of the xml.

[tikitu]

the AttachedDevice section of the outermost scope (i.e. oldest snapshot area)

Are you sure about this? The offending uuid sits outside the first <Snapshot> tag. Seems more logical to me that this location would be for what the GUI calls the Current State.

In the meantime I have managed to hand-edit the xml files to get it started again; mere moments later, after a couple of times restoring a snapshot, the problem recurred.

This process, annoying though it was, has delivered some crucial data: a vmdk file whose name matches the offending uuid does appear in the Snapshots directory, and that filename (and the phantom uuid) changes when the snapshot-restore succeeds. I suspect the problem is with restoring a snapshot, that the current state doesn't get cleaned up properly; possibly the external AttachedDevice section should go back to the latest snapshot but doesn't, for example (whereas if I'm right, the cleanup goes ok in the media registry, thus leading to the mismatch).

I'm going to (grit my teeth and) repeat the procedure again, making a careful record of what changes on a successful and an unsuccessful snapshot-restore, and open a defect ticket.

Thanks for your help!

[mpack]

the AttachedDevice section of the outermost scope (i.e. oldest snapshot area)

Actually, no, I am not at all sure about that - now that you mention it. I avoid snapshots myself, hence I only encounter them when trying to help out other users.

What I know: the xml is clearly partitioned into nested scopes, scopes which represent the same hierarchical structure as the snapshot tree you've seen displayed by the GUI. The most recent snapshot (not precise: I mean the current state) is always shown by the GUI as the most deeply nested element. I've always assumed that the xml structure was the same, but it could easily be inverted.

[mpack]

I'm going to (grit my teeth and) repeat the procedure again, making a careful record of what changes on a successful and an unsuccessful snapshot-restore, and open a defect ticket.

Thanks for your help!

It looks like you may have pinned the problem down better than I have, so thanks for yours!

[Perryg]

I had some issues like this while testing version 4.*.* alpha - beta. Turned out for me it was due to upgrading and the fact that VBox had to actually use the old format and the new format and it was getting confused at times. That's the reason you actually still see snapshot traces in the VirtualBox.xml file IMHO.

I don't use snapshots except to test with and the fix was easy for me. I switched all of my guests to the new format. Now the snapshots show in the new machine xml alone instead of two places. Takes time but the benefits out weighed the hassle. Anyway it may be worth your looking into.

I really wish the DEVs had made a conversion program but they had their reasons why not I suppose. The reason I was given was after converting you could not go back to a previous version.

[tikitu]

I switched all of my guests to the new format.

Any pointers on how to do that? (In the meantime I've isolated the problem and am writing a ticket, but if the fix is just to upgrade the config files... colour me delighted.)

[Perryg]

It's not an easy task with the snapshots. What I found to be the easiest way was to install a new guest. This will use the new format.
Then I was able to see how to move everything and clean out the main xml file.
Adding the snap shots made it a real chore though as I had to replicate the structure by hand.
Make sure you have a full backup before starting. Since this requires you manually editing the xml files and using the long UUID it is easy to fat finger something and end up with a useless guest.

[tikitu]

Sounds like grand fun...

I've opened a ticket: http://www.virtualbox.org/ticket/8648. Maybe that will prompt a less error-prone solution (fat fingers could be my middle name)...

[Perryg]

Yeah I have waited for that for a long time. I do feel your pain and hopefully you will get it fixed soon. As a side note after I finally bit the bullet I have had little to no problems. Most were created by me.... Or so I tell myself.

[mpack]

Do you particularly want to keep the snapshot structure? If not then you could merge them into a single file which would be easier to convert (clone. Then create a new VM with a new hard disk, then replace that hard disk with the clone). After thorough testing you can delete the old VM. Backup is probably a good idea.

[hartnegg]

it's possible that only the error message is new. I.e. possible that the damage was done some time ago, and v4 just has enhanced error checking of the xml.

No, VirtualBox version 4 produces this problem over and over again. Each time I fixed the xml file, it doesn't take long and it's broken again.

[mpack]

No, VirtualBox version 4 produces this problem over and over again. Each time I fixed the xml file, it doesn't take long and it's broken again.

Yes, with the help of all the various threads discussing this issue, the true extent has I think become clear at last.

[mwildam]

Since I also experience this problem now - would it help to export all virtual machines as appliances and re-import to avoid this problem in the future?

[mpack]

No. Export/Import has its own risks.

On the other hand, occasionally backing up your VMs (straight copy, not export) is a good idea. This is easier if you use VirtualBox v4.0 or later and/or avoid the use of snapshots.