problem when I power off the virtual machine using the option to restore the snapshot

[Catalin Amariei]

Most of the times when I close a virtual machine I use the option to reverse it to the last snapshot. The problem is that, when I start "Oracle VirtualBox Manager" it says something about not been able to find a disk and to check. When I check I see one marked with yellow (I guess it's the one previously deleted by VirtualBox). I delete it manually and it works. But it's very annoying (because it's not so rare).

[Catalin Amariei]

error image and log files

[Hammer Faceman]

I have exactly the same problem. My host system is Linux (OpenSuSE 11.4). Guest - WinXP.

[Frank Mehnert]

That is a known problem and reported elsewhere. This will be fixed in VBox 4.0.6 soon.

[Catalin Amariei]

Well, it was not fixed in 4.0.6... I attached the error image and the logs.

[Uwe Geiges]

I also have this problem with 4.0.4 AND 4.0.6.

When this happens, the current Snapshot-Harddisk is deleted and a new one is created, that's correct. But for the MediaRegistry in the *.vbox file the old Snapshot-Harddisk entry is not removed, but the new entry for the new Snapshot-Harddisk is created. The result is a Harddisk that has two children. One of them doesn't exist anymore, and that's probably causing the 'hard disks are not accessible' message.

The bug can easily be triggered without the need to start and close a virtual machine by repeatedly executing the 'restore snapshot' command from the VirtualBox Manager. On my machine, after two or three 'restore snapshot' executions, the corresponding *.vbox file shows the corrupt MediaRegistry.

Host: Windows 7 x64
Guests: Windows XP x86, 7 x64, 2008 R2 x64

[Frank Mehnert]

Still unable to reproduce. Is that VM really stored in an .vbox file or in an .xml file? How many hard disks are attached to this VM?

[Catalin Amariei]

In a .vbox. I will attach it.

PS: now it has 2 snapshots (it had only one before) but there is no difference in error.

[Matti Rintala]

I have the same problem, VirtualBox 4.0.6 with 64-bit OpenSUSE 11.3 host. Restoring a snapshot may cause the VirtualBox Manager to report that the virtual machine is inaccessible. Closing and restarting VirtualBox Manager cures that. But after that Virtual Media shows two VDI files per snaphost, making it impossible to delete anything but the latest snapshot.

I attach two snapshots and my vbox-file.

[Matti Rintala]

vbox-file

[Matti Rintala]

Virtual Media Manager screenshot

[Matti Rintala]

VirtualBox Manager screenshot

[Frank Mehnert]

Unfortunately we are still unable to reproduce this problem. Could you try to find a testcase as simple as possible?

[Uwe Geiges]

I'm not sure how i can help you reproducing the problem. Therefore i just give you more information about my installation:

On my machine the problem occurs on every VM. New ones created with 4.0.6 and "older" VMs created with 3.2.12 - 4.0.4. I first noticed the problem with 4.0.4

Host:

• Intel Core i7-860
  
• 8GB Ram
  
• Windows 7 x64 German
  
• "defaultMachineFolder" points to a different Partition on a different HardDrive -> "E:\VirtualBox"
  
• When VirtualBox Manager is closed it takes about 6 sec for the background process "VBoxSvc.exe" to close
  
• When the problem occurs the harddisk has two children in the MediaRegistry, but never more than two, e.g.:
  

-- After the second "RestoreSnapshot" -> SnapshotHarddisks 1 and 2
-- After the third "RestoreSnapshot" -> SnapshotHarddisks 2 and 3
-- ...

[Wouter Kariboe]

Maybe this helps:

Host: Windows XP Pro +SP3 (32-bit).

Install VBox 4.0.6 (VirtualBox-4.0.6-71416-Win.exe) (with USB support, without any networking options, without Python).

Create a new VM called "openSUSE 11.3". Accept all defaults (RAM 512 MB, dyn. vdi 8 GB).

Create a snapshot ("Snapshot 1").

Start the VM.

"Select Installation Media": select openSUSE-11.3-DVD-i586.iso.

Wait until the VM is in its "openSUSE Installer" window.

Close the VM: select "Power off the machine" and tick "Restore current snapshot 'Snapshot 1'".

After the VM has terminated, the content of the VirtualBox GUI's snapshot tree varies:

1. "Snapshot 1" -> "Current State".

2. "Snapshot 1" -> "Current State (changed)".

(I have no idea what triggers the difference, but I think A is the correct behavior.)

Then quit VirtualBox GUI and wait until Process Explorer indicates that VBoxSVC has terminated. Then restart the GUI.

If the snapshot tree said "Current state" earlier (case A), I get no warning.

However, if the tree said "Current state (changed)" (case B), I get a dialog box "VirtualBox - Warning". Then when I click "Check", the Virtual Media Manager under Hard Disks shows something like:

openSUSE 11.3.vdi ("Attached to: openSUSE 11.3 (Snapshot 1)")

..{a5831124-abed-4633-8e62-2ecb2ab9238b}.vdi ("Attached to: openSUSE 11.3")

...."!" {eccb2282-e0fc-4c84-9b52-869587379e93}.vdi ("Attached to: Not Attached")

(So the "!" vdi is nested within {a5831124-abed-4633-8e62-2ecb2ab9238b}.vdi.)

The "!" vdi-file indeed didn't exist at this point.

Strangely (at least to me...), in openSUSE 11.3.vbox the offending {eccb2282-e0fc-4c84-9b52-869587379e93}.vdi is listed ABOVE {a5831124-abed-4633-8e62-2ecb2ab9238b}.vdi, so not "within" it (as in the GUI's snapshot tree).

I'll attach the related vbox and log files.

[Wouter Kariboe]

A small correction to my previous post:

In the Virtual Media Manager window under Hard Disk, the "!" vdi is actually NOT nested within {a5831124-abed-4633-8e62-2ecb2ab9238b}.vdi, but simply a second daughter of "Snapshot 1", in accordance with the vbox-file (and with the reports by other people).

The problem is strange enough without me making it look even stranger... Sorry about that.

[Frank Mehnert]

Please check if you still see this issue with VBox 4.0.8. We fixed a related bug.

[Uwe Geiges]

After a first check, starting VMs and restoring to last snapshot a few times and also executing several 'Restore Snapshot' commands from the VirtualBox Manager, the corrupt media registry never occurred again.
The problem seems to be solved, for me at least.

Thank you.

[Catalin Amariei]

Seems to be solved on my computer also... Thank you.

[Frank Mehnert]

Thanks for the feedback guys! I will close this ticket, feel free to reopen if necessary.