Removing a VM does not remove media from memory registry.

[mpack]

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.

[Perry G]

Adding name to track ticket

[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.

[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?

[Perry G]

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

[rousseauhk]

Same issue for me (see ​https://forums.virtualbox.org/viewtopic.php?f=34&t=54996)

[Klaus Espenlaub]

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...

[Perry G]

Klaus,

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.

Thanks

[Linux host]

[Perry G]

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?

[Klaus Espenlaub]

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...

[Klaus Espenlaub]

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.

[Klaus Espenlaub]

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.

[Klaus Espenlaub]

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.

[Perry G]

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.

[Frank Mehnert]

r48087 in the public SVN.

[Perry G]

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.

[Perry G]

Yes it works now. Thanks you so much.

[Frank Mehnert]

Fixed in VBox 4.2.18.