Ticket #10311 (closed defect: fixed)

Opened 2 years ago

Last modified 8 months ago

Removing a VM does not remove media from memory registry.

Reported by: mpack Owned by:
Priority: major Component: other
Version: VirtualBox 4.1.8 Keywords: media registry remove
Cc: Guest type: other
Host type: other


Scenario: you want to move a VM to a new drive. Procedure: copy the VM folder, then in UI you right click the VM and select "Remove", then "Machine|Add" to add back the ".vbox" from its new location.

This operation fails with a error msg saying that the .VDI file already exists: obviously the memory resident media registry was not updated by the "Remove". Current workaround I know is to close VirtualBox, wait a while, then start it again, then Machine|Add works.

Change History

comment:1 Changed 2 years ago by Perryg

Adding name to track ticket

comment:2 Changed 2 years ago by mpack

Sorry, I should have included that I tested and found this behaviour on an XP Pro 32bit host. I have not tested other hosts.

comment:3 Changed 13 months ago by mpack

This issue is really becoming a pain in the ass. It affects all kinds of manipulations of VMs, confusing users with nonsensical errors. Any chance of a formal response?

comment:4 Changed 12 months ago by Perryg

I have to agree with Don. I move guests around a lot and this is starting to get ridiculous.

comment:5 Changed 12 months ago by rousseauhk

comment:6 Changed 8 months ago by klaus

Sorry, but this ticket has a severe lack of facts, and in particular it would be helpful to see the VM config file which doesn't work. Our own testing so far hints that this is limited to VMs which use at least one medium which is in the global medium registry (see ~/.VirtualBox/VirtualBox.xml, tag <MediumRegistry>.

Can anybody confirm (preferrably with a .vbox/.xml file which should lack the MediumRegistry for at least some of the hard disks)? This would mean that the affected VMs predate the switch to per-VM (well, mostly) media registries, and such VMs simply can't be moved around like this. VMs with their own media registry will have all their media automatically unregistered when the VM is unregistered (because they're self-contained), but of course stuff in the global media registry can't be handled this way.

Or are you talking about complex linked clone structures? These are also very complicated to move around because several VMs share at least some images...

comment:7 Changed 8 months ago by Perryg


I just tested this again today since you posted. It used to (for me IIRC) fail to update the master control file VirtualBox.xml unless I shut down the VMM and waited for the VBoxSVC to stop and then I could start the VMM and proceed with the add. But today this does not seem to be the issue. For what ever reason it appears to be working properly. I will watch it for a few days and let you know if it fails.


[Linux host]

comment:8 Changed 8 months ago by Perryg

I take it back. After closing and starting the main manager the guest says it is in accessible.

VirtualBox.xml shows the guest and associated UUID VBoxSVC says it does not exist.

All guests are of the *.vbox generation not the old machine HDD separate folder stuff.

So while it lets me remove and add it back in now it fails to actually retain the information unless I shut the main manager down before I add it back.

So I take it you can not reproduce this nasty little bug?

comment:9 Changed 8 months ago by klaus

Hey, just managed to reproduce it with one of my VMs, which has a giant snapshot tree (it's the VM I used for testing the issue with hitting the snapshot depth limit in 4.2).

Unregistering the VM left behind a big, media tree which wasn't used by any VM. Not supposed to happen. Of course this will then cause trouble with the medium registry when moving the VM to a different place, "Cannot register the hard disk '/path/to/disk.vdi' {uuid} because a hard disk '/old/path/to/disk.vdi' {uuid} already exists." - only exact duplicates are ignored, which means that this won't show up if one re-registers the VM without moving it elsewhere.

So there's clearly a problem with handling the medium registry as part of the VM unregistering. Let's see how hard it is to get this fixed...

comment:10 Changed 8 months ago by klaus

Oh, and just in case I'd otherwise fail to mention it: the workaround is unregistering all media used by the VM, using the Virtual Media Manager in the GUI or VBoxManage closemedium.

comment:11 Changed 8 months ago by klaus

Really interesting. The API is actually behaving 100% as designed here... Both VBoxManage and the GUI are using CleanupMode_DetachAllReturnNone for unregistering without deleting the media, which is explicitly documented as "this will keep all media registered". It's actually a bug on the client side, shared by VBoxManage and the GUI without sharing code.

comment:12 follow-up: ↓ 13 Changed 8 months ago by klaus

The fix for this is in trunk and the internal 4.2 branch, so it will be fixed whenever the next 4.2 release is done and/or the next 4.3 beta is out.

comment:13 in reply to: ↑ 12 Changed 8 months ago by Perryg

Replying to klaus:

The fix for this is in trunk and the internal 4.2 branch, so it will be fixed whenever the next 4.2 release is done and/or the next 4.3 beta is out.

What is the release number my friend?

I realise that this was just a nit that could be worked around, but I really appreciate it being fixed.

comment:14 Changed 8 months ago by frank

r48087 in the public SVN.

comment:15 Changed 8 months ago by Perryg

Thanks Frank.

I already have that build in place, but had not read the change log that close and have not tried to replicate the issue. I'll test later today.

comment:16 Changed 8 months ago by Perryg

Yes it works now. Thanks you so much.

comment:17 Changed 8 months ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in VBox 4.2.18.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use