VirtualBox Plugin starts Vbox daemons

Bug #603802 reported by Juan Simón
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
kupfer
Fix Released
Undecided
Karol Będkowski

Bug Description

This bug is related to the other error that I reported to VirtualBox: http://www.virtualbox.org/ticket/6866#comment:1

The VirtualBox plugin of Kupfer starts VirtualBox daemons and this consumes resources, it breaks the normal VB behaviour and this blocks the upgrade process of VB in Ubuntu.

Revision history for this message
Juan Simón (simonbcn) wrote :

kupfer compiled from sources, git version.
Ubuntu 10.04 32 bits
Oracle VM VirtualBox 3.2.6-63112

Revision history for this message
Karol Będkowski (karol-bedkowski) wrote :

Unfortunately, this is normal behavior when you are using vboxapi.
You can try use this patch: http://github.com/KarolBedkowski/kupfer-adds/commit/879c3b951c61e5abbcb1be59f0539919a61762ce
and option "Force use cli interface".

Revision history for this message
Juan Simón (simonbcn) wrote :

There is other way. Gnome-do has a plugin with same functionality and it doesn't fail in this.

Revision history for this message
Karol Będkowski (karol-bedkowski) wrote :

In Kupfer we're using two ways. If you have Sun/Oracle VirtualBox, we try to use vboxapi - python interface
If you don't have his version or vboxapi fail - we use cli interface (via VBoxManager - exactly like GnomeDo).
So there is no other way. With my patch you can force use "cli" interface, even if vboxapi seems to works ok.

Revision history for this message
X (u78qir8a9-deactivatedaccount) wrote :

Karol -- can we "force cli" by default? I never use VirtualBox nor do I test it, but its python module is very intrusive and I had the feeling even before this that it's nothing I would like to load into my Kupfer (because it changes sys.path and other worse things, it's not something that Kupfer likes -- an application can't accept its modules and plugins modifying too much of the application-global settings).

Revision history for this message
Karol Będkowski (karol-bedkowski) wrote :

Using python interface to manage vbox is faster. When you asking vbox about state of virtual machine or simple list registered vms, this take some time - about 1-3 seconds. With python api response is much faster.
Fortunately python api don't change to often - as far I remember it was first change from long time.

Revision history for this message
X (u78qir8a9-deactivatedaccount) wrote :

Ok that sounds good. Can I ask you to update your vbox4 branch again? I think it has a trivial error with not importing plugin_support. I'll merge it after that.

Revision history for this message
Karol Będkowski (karol-bedkowski) wrote :

Fixed & rebased.

Thanks.

Revision history for this message
X (u78qir8a9-deactivatedaccount) wrote :

Is it possible to postpone importing vboxapi until VBoxMachinesSource.initialize is called? (Then try to set VBoxMachinesSource.appleaf_content_id in the same function, I hope that works)

It would be good if we did not import vboxapi at all, especially when force_cli is configured. Remeber that in Python, importing a module is the same thing as executing a lot of code.

Also it would be cool if there is a way to unload & shut down vboxapi + daemons and call that in VBoxMachinesSource.finalize (this is called when the plugin is disabled). Of course we must only kill those daemons that we started. But that way the user can disable the plugin to solve the problem maybe(?)

Revision history for this message
Karol Będkowski (karol-bedkowski) wrote :

I've updated this plugin.
Now modules are unloading when plugin is disabled/enabled and after change of "force cli" option.

Vbox daemons (VBoxXPCOMIPCD and VBoxSVC) should shut down themself after some time when they are idle.

Revision history for this message
X (u78qir8a9-deactivatedaccount) wrote :

Thank you, I have merged your changes. I removed one part. I have to take back the module unloading part -- there is no real python module unloading.

Yes, we do some ugly stuff in kupfer.core.plugins for loading/unloading plugins but the unloading is only some bookkeeping. To really save memory you have to restart kupfer after disabling plugins.

What we want however is that plugins that are disabled also disable their notifications and any daemons if any they started. That was what I was trying to say -- if the virtualbox plugin starts a daemon, it has to stop it when the plugin is disabled too.

Anyway, the change to not import 'vboxapi' at all until we know that we really want to do that -- that's the important part.

Revision history for this message
Karol Będkowski (karol-bedkowski) wrote :

Ok, Thanks.

Virtualbox daemon work similar like dbus - on first connect it starts and when is no longer necessary - it shunting down. Unfortunately I don't see any method to shutdown daemon without kill it. But killing also stop running virtual machines so it's unacceptable.

Anyway - we don't listen to any signals from virtualbox, so still running daemon after disable plugin is no problem.

Revision history for this message
X (u78qir8a9-deactivatedaccount) wrote :

Thanks this is fixed as far as we can in the code.

I think we must add documentation for each plugin.

Changed in kupfer:
assignee: nobody → Karol Będkowski (karol-bedkowski)
status: New → Fix Committed
Changed in kupfer:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.