-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up Vbox VMs #5424
Comments
Do you remember which project you ran? At least LHC@home is using this pattern for VM names (example): Recent logs show that deregistering/removal works fine with vboxwrapper 26206 used there:
Using a vboxwrapper instance to remove a VM not under it's own control may cause trouble:
As long as those instances run under the same user account their vboxmanage requests are queued by VirtualBox and finally written to/removed from the same VirtualBox.xml file. |
I believe, we still need some kind of clean-up that will check next:
Because there always can happen some situations when vboxwrapper might fail deregistering/removal of the VM, and it will stuck in the VBoxManager forever |
As for (1.) As for (2.) As for (3.) |
I think, this should be a functionality of the BOINC client, and completely decoupled from the vboxwrapper, because if might happen that there were no VBox tasks for quite a long time, and we need to clean up some orphan VMs.
I does |
I agree that VM cleanup should be done by the client. Also, has anyone besides me seen this issue? |
VM names like "boinc_4e84e6a8a719072c" are used at least by LHC@home and cosmology@home. As long as the orphan machine entries are only in VirtualBox.xml they may confuse a user looking through VirtualBox Manager but in fact they do not affect fresh BOINC work. Complaints about that have been posted in the past but not recently in the forums from LHC@home. |
Users can remove these entries manually. |
I see it too, I just go in an clean them up by hand or manually use vboxmanage to clean them up. I think it was worse in the past than now but just a feeling, to support computezrmle comment I hypothesis is it could be on a reboot of th computer, I run a shell script on linux/win to wait for all the VMs to close down before rebooting since the OS is not paitent enough to wait ~2 min for the VMs to close down. You could compare the entries in VirtualBox.xml to the BOINC know list and remove the excess? |
(Win) when I open VirtualBox Manager, there are dozens of entries in the VM list
with names like boinc_091b568ebb08451b, pointing to nonexistent slot directories.
These shouldn't be there; should be cleaned up by vboxwrapper.
The text was updated successfully, but these errors were encountered: