[Solved] Could not find an open hard disk with UUID

[macsek]

Hi,

I used VirtualBox for half a year with an Ubuntu 20.04.2 LTS on a win10 enterprise 10.0.18363 build 18363. The system runs on a Dell Latitude E5470, Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2401 Mhz, 2 cores, 4 virtual processors, 16GB RAM, UEFI BIOS BIOS Dell Inc. 1.22.3, 2020.02.17., occasionally restarting windows host on average 6-8 weeks. I use an external monitor in addition to the built-in laptop display and a docking station, mostly connected to wired ethernet, sometimes to WiFi. The main use of this ubuntu is text-based system administration (ssh terminal sessions).

A few days ago (8th July, 2021) the virtual machine has stopped (system usage was very light: some tabs open on Firefox, idle for some hours, a text editor, some terminal sessions). VirtualBox menu system was working, but could not control the guest OS to have a safe reboot, so finally had to power it off. Guest OS does not start since this power off, virtual machine is Inaccessible, "Could not find an open hard disk with UUID".

2021-07-12_09h57_49.png (49.88 KiB) Viewed 8585 times

Could not find an open hard disk with UUID {f2b41640-96ea-404c-9e0f-bd294e5a8895}.
Result Code:
VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
Component:
VirtualBoxWrap
Interface:
IVirtualBox {d0a0163f-e254-4e5b-a1f2-011cf991c38d}

I have made a backup of the virtual machine folder.

I have tried to start the virtual machine after copying c:\Users\me\VirtualBox_VMs\Ubuntu_20.04\Ubuntu_20.04.vbox-prev to Ubuntu_20.04.vbox, but the fault remained. This files are attached.
Original vbox file contains the breakdown timestamp: lastStateChange="2021-07-08T18:54:40Z" aborted="true".

VirtualBox Media Manager displayed it cannot access this virtual hard drive. I have removed the virtual disk from the media list and re-added it. The original virtual machine still could not access it, so I had created a replacement virtual machine, adding the very same virtual disk file. It did start, I am using it currently but the data is some months old on the virtual hard disk.

There are some files in the original virtual machine snapshots directory, the date of one of them is 8th July, probably the missing data could be accessed. (I have changed my username here)

Microsoft Windows [Version 10.0.18363.1556]
(c) 2019 Microsoft Corporation. Minden jog fenntartva.

C:\Users\me\VirtualBox_VMs\Ubuntu_20.04\Snapshots>dir
Volume in drive C is Windows
Volume Serial Number is A08F-2CEB

Directory of C:\Users\me\VirtualBox_VMs\Ubuntu_20.04\Snapshots

2021.06.23. 13:55 <DIR> .
2021.06.23. 13:55 <DIR> ..
2021.01.29. 16:30 176 441 810 2021-01-29T14-30-07-043318500Z.sav
2021.06.22. 18:25 181 053 853 2021-06-22T16-25-18-562748700Z.sav
2021.06.22. 08:26 2 097 152 {42dfd8da-d2f0-4bcd-8106-9b73339eb37d}.vdi
2021.07.08. 20:18 29 084 352 512 {f2b41640-96ea-404c-9e0f-bd294e5a8895}.vdi
4 File(s) 29 443 945 327 bytes
2 Dir(s) 21 892 673 536 bytes free

C:\Users\me\VirtualBox_VMs\Ubuntu_20.04\Snapshots>

Questions:
Q1: Do you need more information to create a bug report to get this bug removed from VirtualBox? If so please specify. Config/log files I thought can be useful are attached.

Q2: How can I access the latest data stored on the original virtual hdd? (I have a backup of the broken files)

Thanks in advance.
Laszlo

[mpack]

There is no magic problem or solution here. When files go missing it is usually by user action, e.g. folders moved or renamed, files renamed or deleted.

Go into the .vbox file for that VM and look in the media registry section for that UUID. See what the file name and path is for the VDI, then go looking for it (hopefully the media is at least registered by the correct VM).

Edit:  Ah, I didn't notice that you had attached the .vbox file. I see that UUID {{f2b41640-xxx} is mounted in the IDE drive of that VM, but the VM does not register any such hard disk. Therefore some other VM did. And the erroneous folder/file renaming or deletion was to the other VM. Did you delete or move any old VMs recently?

[macsek]

There is no magic problem or solution here. When files go missing it is usually by user action, e.g. folders moved or renamed, files renamed or deleted.

Go into the .vbox file for that VM and look in the media registry section for that UUID. See what the file name and path is for the VDI, then go looking for it (hopefully the media is at least registered by the correct VM).

Edit:  Ah, I didn't notice that you had attached the .vbox file. I see that UUID {{f2b41640-xxx} is mounted in the IDE drive of that VM, but the VM does not register any such hard disk. Therefore some other VM did. And the erroneous folder/file renaming or deletion was to the other VM. Did you delete or move any old VMs recently?

Thanks for your efforts.
I have the backup of the virtual machine folder (including the snapshots folder), and I have not deleted/moved any VMs recently, but deleted the unaccessible virtual hard drive, added it again and attached to the freshly created VM (ubi2, its config file can also be found in the uploaded archive). No other VM modification was made.

[mpack]

I already checked the "ubi2" VM, and it does not register the missing media. If it did then there would be no problem - a VM can use media registered by other VMs (it's a bad idea, but it's allowed).

In fact I was wasting my time when I checked "ubi2". We know in advance that no VM registers media with that UUID, otherwise the reported error message would not happen.

I should also mention that your "Ubuntu_20.04" VM does register a hard disk with UUID {eed35936-xxx}, called "Ubuntu20.04.vdi" which it does not reference. Why does it do that? A VDI with that name would normally indicate the primary hard disk of the VM. The most reasonable explanation I can think of is that the Ubuntu VM is a clone, that after creating the clone you detached the default hard disk and used the Storage panel to reference a hard disk owned by another VM, and then you deleted the other VM.

[macsek]

I already checked the "ubi2" VM, and it does not register the missing media. If it did then there would be no problem

Yes, then "Ubuntu_20.04" would also access it.

I should also mention that your "Ubuntu_20.04" VM does register a hard disk with UUID {eed35936-xxx}, called "Ubuntu20.04.vdi" which it does not reference.

Good catch.
This excerpt is from "ubi2":

Code: Select all

        <StorageController name="SATA" type="AHCI" PortCount="1" useHostIOCache="false" Bootable="true" IDE0MasterEmulationPort="0" IDE0SlaveEmulationPort="1" IDE1MasterEmulationPort="2" IDE1SlaveEmulationPort="3">
          <AttachedDevice type="HardDisk" hotpluggable="false" port="0" device="0">
            <Image uuid="{eed35936-7fdf-4ae5-811d-c53f45d5341f}"/>
          </AttachedDevice>
        </StorageController> 

"Ubuntu_20.04" VM contains a different UUID, even if the HardDisk section refers to the same UUID as "ubi2" does.

Code: Select all

    <MediaRegistry>
      <HardDisks>
        <HardDisk uuid="{eed35936-7fdf-4ae5-811d-c53f45d5341f}" location="Ubuntu20.04.vdi" format="VDI" type="Normal"/>
      </HardDisks>

Code: Select all

<Image uuid="{f2b41640-96ea-404c-9e0f-bd294e5a8895}"/> 

Quite strange.
However I have restored the "Ubuntu_20.04" VM folder from the backup and changed the image UUID to the same as the HardDisk uuid and this way the virtual machine has started. There was still the same data loss as in "ubi2" VM which is no strange as the references became the same this way.

Why does it do that? A VDI with that name would normally indicate the primary hard disk of the VM. The most reasonable explanation I can think of is that the Ubuntu VM is a clone, that after creating the clone you detached the default hard disk and used the Storage panel to reference a hard disk owned by another VM, and then you deleted the other VM.

It could have been, but in fact "Ubuntu_20.04" was created from scratch.

The main question is still the use of Snapshot data, I hope if the VM would use them I could access the missing files too. Do you think this is the way to go? What is the way to force using the Snapshots? Thanks.

[macsek]

The main question is still the use of Snapshot data, I hope if the VM would use them I could access the missing files too. Do you think this is the way to go? What is the way to force using the Snapshots? Thanks.

I have successfully set the VM to use the snapshot, so I can access my files. Thanks for your time, mpack.
I had to add the big snapshot file I had in the Snapshots folder using the Virtual Media Manager. It was shown under the Ubuntu_20.04.vdi image. I set the virtual machine hard disk to be the snapshot file and started it.

Question 1: Can I file a new bug report to eliminate the possible sw fault which led to this situation and does it worth the effort? I would like to think this bug won't hurt anyone from now on.

Question 2: how can I merge the 24 GB Ubuntu_20.04.vdi image and the 27 GB snapshot to reclaim the space occupied? (Their virtual size is 35GB). Thanks in advance.

[mpack]

Question 1: Can I file a new bug report to eliminate the possible sw fault which led to this situation and does it worth the effort? I would like to think this bug won't hurt anyone from now on.

I wouldn't bother - with no clear evidence of a reproducable bug it would be ignored. In fact I've seen no evidence of a bug: VirtualBox has been known to randomly corrupt config files, but there was nothing random about this. This was clearly user error.

Regarding your VM with the snapshots: if you now have this running to your satisfaction then I suggest that you clone it, current state only (i.e. discarding the snapshots). A VM in which the snapshot structure has been messed with manually by a non-expert (or even by an careless expert!) is too dangerous to keep around. I myself do not use snapshots, period. I also don't use related features such as linked clones.

[macsek]

Question 1: Can I file a new bug report to eliminate the possible sw fault which led to this situation and does it worth the effort? I would like to think this bug won't hurt anyone from now on.

I wouldn't bother - with no clear evidence of a reproducable bug it would be ignored.

Thanks.

In fact I've seen no evidence of a bug: VirtualBox has been known to randomly corrupt config files, but there was nothing random about this. This was clearly user error.

Just to learn from the case: where do you see a user error? VBox has not responding, was not even to able to power off the running guest OS. After powering off it did not see the hard disk file any more.

Regarding your VM with the snapshots: if you now have this running to your satisfaction then I suggest that you clone it, current state only (i.e. discarding the snapshots). A VM in which the snapshot structure has been messed with manually by a non-expert (or even by an careless expert!) is too dangerous to keep around. I myself do not use snapshots, period. I also don't use related features such as linked clones.

Correct: the config files currently are hand-modified, better to have something new set-up. Thanks for the idea.
For the later readers: Cloning is described on the official oracle documentation page https://docs.oracle.com/en/virtualizati ... clone.html and on this tutorial page {deleted by mod}.

[mpack]

This was clearly user error.

Just to learn from the case: where do you see a user error?

A hard disk belonging to VM A was mounted in VM B, which already had its own hard disk. You can only do this in the Storage panel in the VM settings. There's no way it was a VirtualBox bug - no mechanism to do that exists in VirtualBox, buggy or otherwise. This was by user action, either deliberate or in error.

The only bullet-proof solution I would suggest is: avoid use the Storage panel. Create your disks along with your VMs, and never reassign them. Also avoid snapshots, since those are always a catastrophe waiting to happen.

I removed one of your links. Please do not post links to external blogs or learning sites, as that gives them an air of authenticity which is unwarranted since we don't vet such sites for accuracy. All authentic information about VirtualBox comes from the user manual, and to a lesser extent, these forums.

Besides which, ISTM the user manual gives a pretty good description of cloning a VM.
https://www.virtualbox.org/manual/UserManual.html#clone.

[macsek]

This was clearly user error.

Just to learn from the case: where do you see a user error?

A hard disk belonging to VM A was mounted in VM B, which already had its own hard disk. You can only do this in the Storage panel in the VM settings. There's no way it was a VirtualBox bug - no mechanism to do that exists in VirtualBox, buggy or otherwise. This was by user action, either deliberate or in error.

Well, before the error has happened I have not done it so. All of the VM files in question were originally put in one directory c:\Users\me\VirtualBox_VMs\Ubuntu_20.04\ by VBox by the time of the creation of the VM. Using Snapshots without terminating them for months was my fault of course.

The only bullet-proof solution I would suggest is: avoid use the Storage panel. Create your disks along with your VMs, and never reassign them. Also avoid snapshots, since those are always a catastrophe waiting to happen.

Thanks, that sounds reasonable. And yes, the catastrophe has happened in my case after some months.

I removed one of your links. Please do not post links to external blogs or learning sites, as that gives them an air of authenticity which is unwarranted since we don't vet such sites for accuracy. All authentic information about VirtualBox comes from the user manual, and to a lesser extent, these forums.

Sure, thanks for the modification.
Also thanks for your time to investigate and teach.
Should I rename the thread to have SOLVED: prefix?

[mpack]

Should I rename the thread to have SOLVED: prefix?

No need, I just did it for you. Thanks for reporting back.

[macsek]

Should I rename the thread to have SOLVED: prefix?

No need, I just did it for you.

Thanks