VM inaccessable after host crash

[Eric!]

I have the following error after a crash due to a power outage:

Code: Select all

Cannot attach medium '/usr/share/virtualbox/VBoxGuestAdditions.iso' {7454108f-ee93-478b-ab23-ca4459da5137}: medium is already associated with the current state of machine uuid {ac47d6b8-276f-4d76-b7a8-6a4c2d18af48}!.

Result Code: VBOX_E_OBJECT_IN_USE (0x80BB000C)
Component: MediumWrap
Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}

My host system is Linux i5 4.15.0-64-generic #73-Ubuntu SMP Thu Sep 12 13:16:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

And I can't seem to release the images as the options are greyed out. I'm not sure what to do here to restart my VM. Any help would be appreciated.

[mpack]

The host crash had nothing to do with this, except perhaps it forced you to restart your VM. No amount of crashes will cause VirtualBox to add two DVD drives to your VM recipe, with the same ISO mounted in both. That is user error: failure to understand the difference between adding media to a drive, and adding a new drive.

Your repaired .vbox file is below.

p.s. You'll find that zip files are more convenient for attachments, and it saves space on the server.

[socratis]

Not to be too pedantic here, but:

... device="0" />

has an extra space before the closing tag. It works and it's accepted, but according to strict XML rules the way VirtualBox does it, it should be:

... device="0"/>

Hope you'll excuse my <there's got to be something named after that> syndrome 'mpack'...

Edit:

Fixed erroneous statement from "strict XML rules" to "the way VirtualBox does it".

[mpack]

Pedantry is ok, provided you get it right!

according to strict XML rules it should be:

... device="0"/>

Can you quote a reference for that? Because I'm afraid it sounds like BS.

I've been writing parsers for 30 years, and whitespace between tokens is normally irrelevant. The tokens in that sequence are

"device", "=", ""0"", "/>".

That sequence is not altered by adding or removing whitespace (spaces and tabs) between the tokens. In some languages (e.g. all Algol derivates such as C and Pascal) a newline is also treated as whitespace so it too would be equally irrelevant, in others the newline is a statement terminator so would not be allowed inside that token sequence. I'm not sure where XML stands on newlines: but I suspect the rules probably differ for attributes (such as the above) vs body text, so I'm pretty sure that newlines ought to be allowed as well.

[socratis]

Can you quote a reference for that? Because I'm afraid it sounds like BS.

You're right! I don't have a reference for the space in the termination tag, I simply went with what VirtualBox does. I edited my previous post and corrected my statement. I don't know what the RAM in my head was pointing to, faulty chip perhaps?

The only reference that I could find in the official documents (XML specification » 3.1 Start-Tags, End-Tags, and Empty-Element Tags), has a single example which both a space is allowed and not. I remember there were some validators years ago that were warning about the extra space in special elements.

I'm not sure where XML stands on newline ... I'm pretty sure that newlines ought to be allowed as well

I think so too. Again, based on the official XML specification » 2.3 Common Syntactic Constructs:

white space consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs

[mpack]

I made no assumptions, I simply read the error message and looked at your .vbox file. This has nothing to do with cloning the image, and anyway the message clearly indicates that the problem is with the Guest Additions ISO, not your disk image.

I don't think you replaced the .vbox file, there's no other way it can still have a memory of the "7454.... " UUID, which I completely deleted.

Edit:

I see that you have now deleted the post that this refers to.

[socratis]

there's no other way it can still have a memory of the "7454.... " UUID, which I completely deleted

Just like the OP's reply, things have a tendency to get deleted on this thread!

I was about to reply in the same spirit as you Don, but when I tried to reload the page, the OP pulled a "Keyser Söze" on us:

And like that... pfft... he's gone.

[Eric!]

I'm right here. I spent a lot of time trying to find the cause of the problem. But it seems like when it crashed and booted back up the VM was inaccessible. I didn't do anything to it and copied them over. I spent a lot of time going back through it and I have no idea why that is in the vbox file. It makes me a little nervous to use the VM environment when suddenly like that it fails to work and there's no clear reason why that happened or how to fix it.

[socratis]

there's no clear reason why that happened or how to fix it.

No clear way how to fix it? I'm sorry, but 'mpack' gave you the .vbox file to replace your existing one, how's that no way to fix it exactly?

[Eric!]

there's no clear reason why that happened or how to fix it myself.

Seriously guys. Such a cryptic error message for someone just using virtualbox for the first time and to be locked out of the machine and unable to locate my data using the testdisk tool. There was no forced restart or anything. Upon booting it up again and starting virtualbox it told me the image was inaccessible. I've used vmware a lot but I've never seen something like that happen. I did a lot of searching and found nothing really related, but a lot of results. It still is unclear to me even now what caused it to completely fail like that. And it isn't clear to me how to recover my data using a method like this because it didn't work as I expected either: https://askubuntu.com/questions/425518/ ... achine-vdi

Sure it's probably simple solution to those who understand virtualbox and how it works with the xml file. I appreciate the help even if it's difficult to lower yourself to my level of understanding.

[socratis]

there's no clear reason why that happened or how to fix it myself.

The why it happened is analyzed below. Fixing it yourself? Not that easy, if not explained...

Let's start from the analysis of your .vbox, the "recipe" of the VM. Open it with a text editor, it's a simple XML file. At the beginning you have your <MediaRegistry> section, which holds all known present and past media, with two major entities; <HardDisks> and <DVDImages>:

<MediaRegistry>
  <HardDisks>
    <HardDisk uuid="{0c2b59d5-7bee-4500-8f29-e18688670dd4}" location="LUbuntu 18.04lts.vdi" format="VDI" type="Normal">
      <HardDisk uuid="{d980c489-8e64-499d-b035-9dd2823e67e3}" location="Snapshots/{d980c489-8e64-499d-b035-9dd2823e67e3}.vdi" format="VDI">
        <HardDisk uuid="{0a4a0e3a-c307-45c4-9752-99463161f2b3}" location="Snapshots/{0a4a0e3a-c307-45c4-9752-99463161f2b3}.vdi" format="VDI"/>
      </HardDisk>
    </HardDisk>
  </HardDisks>
  <DVDImages>
    <Image uuid="{37a98e10-c474-4d65-849c-95d14d93fb04}" location="/media/esb/1TB/home/owner/Downloads/lubuntu-18.04.1-desktop-amd64.iso"/>
    <Image uuid="{7454108f-ee93-478b-ab23-ca4459da5137}" location="/usr/share/virtualbox/VBoxGuestAdditions.iso"/>
  </DVDImages>
</MediaRegistry>

You can see that you had your original VDI ("LUbuntu 18.04lts.vdi") and then you made a snapshot ("Snapshots/{d980c489..."), and then another snapshot ("Snapshots/{0a4a0e3a..."). You can tell that from the indentation level as well.

And then you have your two ISOs; the "lubuntu-18.04.1-desktop-amd64.iso" from which you made the installation, and the "/usr/share/virtualbox/VBoxGuestAdditions.iso" with a UUID of "{7454108f-ee93-478b-ab23-ca4459da5137}", which you mounted at some point in order to get the GAs installed. This BTW is your problem, so we'll be focusing on that later on.

As I mentioned, you have two snapshots. If you use your text editors "Search" functionality to search for "7454108f" (the initial part of your GAs ISO UUID), you'll find it in several places. I'll just give you the instances along with the line numbers, do that yourself as well.

From your Media Registry:

[quote] 18   <DVDImages>
 19     <Image uuid="{37a98e10-c474-4d65-849c-95d14d93fb04}" location="/media/esb/1TB/home/owner/Downloads/lubuntu-18.04.1-desktop-amd64.iso"/>
 20     <Image uuid="{7454108f-ee93-478b-ab23-ca4459da5137}" location="/usr/share/virtualbox/VBoxGuestAdditions.iso"/>
 21   </DVDImages>[/quote]

IDE Storage Controller, with 2 (TWO) CD/DVD drives, "Snapshot Init", GAs ISO mounted on Port0:

[quote] 77         <StorageController name="IDE" type="PIIX4" PortCount="2" useHostIOCache="true" Bootable="true">
 78           <AttachedDevice passthrough="false" type="DVD" hotpluggable="false" port="1" device="0"/>
 79           <AttachedDevice passthrough="false" type="DVD" hotpluggable="false" port="0" device="0">
 80             <Image uuid="{7454108f-ee93-478b-ab23-ca4459da5137}"/>
 81           </AttachedDevice>
 82         </StorageController>[/quote]

Same picture with "Snapshot 1":

[quote]136             <StorageController name="IDE" type="PIIX4" PortCount="2" useHostIOCache="true" Bootable="true">
137               <AttachedDevice passthrough="false" type="DVD" hotpluggable="false" port="1" device="0"/>
138               <AttachedDevice passthrough="false" type="DVD" hotpluggable="false" port="0" device="0">
139                 <Image uuid="{7454108f-ee93-478b-ab23-ca4459da5137}"/>
140               </AttachedDevice>
141             </StorageController>[/quote]

But, in your current state you had:

[quote]200       <StorageController name="IDE" type="PIIX4" PortCount="2" useHostIOCache="true" Bootable="true">
201         <AttachedDevice passthrough="false" type="DVD" hotpluggable="false" port="1" device="0">
202           <Image uuid="{7454108f-ee93-478b-ab23-ca4459da5137}"/>
203         </AttachedDevice>
204         <AttachedDevice passthrough="false" type="DVD" hotpluggable="false" port="0" device="0">
205           <Image uuid="{7454108f-ee93-478b-ab23-ca4459da5137}"/>
206         </AttachedDevice>
207       </StorageController>
[/quote]

You have TWO instances of the same disk! That confuses the heck out of VirtualBox, and it needs manual intervention, a minor "surgery" that can only be performed manually by experienced users, just what 'mpack' did for you.

The reason is that you had *two* DVD drivers, and you loaded both of them with the *same* DVD. The "mistake" started when you didn't realize that you don't need to add a second driver to load the GAs ISO. I bet that you saw that on a blog/vlog somewhere from an ignorant fool!

You don't go out to the market and get yourself a DVD drive, just to play a CD, do you? Well, technically that's exactly what you did. Instead of inserting the GAs ISO into the existing DVD drive, you went ahead and created a 2nd DVD drive, and then you inserted the GAs ISO. Not only that, but you tried to insert the same ISO in the 1st drive as well...

'mpack' removed all instances of your GAs ISO and gave you a clean one.

[mpack]

There probably is a minor VirtualBox bug involved here, which in conjuction with user error creates this issue.

When asked to insert a CD (ISO) into a virtual drive, VirtualBox first looks for the drive to use. I suspect it defaults to the last CD drive in the list (VM recipe). It then checks if the ISO is already mounted in the CD drive. Finding that it isn't, VirtualBox mounts the CD in the drive.

For most people this bug is harmless since most people don't add multiple CD drives to the VM. I'm not very clear on what provokes nooby users to do so. I suspect it goes something like this (Linux Guests only, since I think VERR_PDM_LOCKED only happens when a drive is mounted by a Linux guest) :-

1. At some time in the past the user successfully "Inserted the GAs CD", autorun kicked in and the GAs were installed. The user forgot to remove the CD from the drive after that.
2. At some later time the user wanted to update the GAs, so they tried "Inserting" the GAs CD again. However this time they got a VERR_PDM_LOCKED error because the GAs ISO was already mounted (still there from last time).
3. Rather than browse to the CD and run the install script directly, the user then reverts to random acts: restarting VM, retrying the "Insert" thing again etc.
4. Finally, the user discovers that if he drops out to the VM manager and adds a new CD drive, then the "GAs Insert" thing works once more (emphasis on "once"). This is the VirtualBox bug: you shouldn't be able to mount the same media twice, you should continue getting the PDM_LOCKED error.