need option to prevent VBOX protocol on first run/connect

[onlyjob]

I have a big problem with default population of VBOX sessions.

On first run/connect I have many VBOX sessions which are hardly distinguishable from applications I'd like to connect to.

One problem is that all of them are not running but if accidentally clicked VBOX is starting VM which takes significant portion of RAM. If started VM is hard to terminate until guest OS is loaded.

More specifically the problem is that VBOX virtual machine which hasn't been started yet looks like already running applications.
(VMs that are not running and not even suspended are shown as sessions)

I have many VMs configured and this is cluttering menu at the same time increasing chances of accidental VM starting.

The only way to stop this behaviour that I know if to modify file

~/.winswitch/server/protocols/virtualbox.conf
to make sure it have "enabled=False"

However first run of Winswitch populates all VMs (which slows down the startup) and I have to modify .conf file and restart Winswitch in order to have desirable configuration.

It would be nice if Winswitch will

• not initialise VBOX sessions by default;

• obey existing Configuration --> Protocols --> Virtualbox;

• if necessary have another (new) configuration to control this behaviour.

I tried to modify the code responsible for creation of
~/.winswitch/server/protocols/virtualbox.conf
with "enabled=True" but couldn't find how it is done.

Please advise.

Thank you.

[Antoine Martin]

The only way to stop this behaviour that I know if to modify file

~/.winswitch/server/protocols/virtualbox.conf
to make sure it have "enabled=False"

However first run of Winswitch populates all VMs (which slows down the startup) and I have to modify .conf file and restart Winswitch in order to have desirable configuration.

It would be nice if Winswitch will

• not initialise VBOX sessions by default;

ok, but how would you initialize them?

• obey existing Configuration --> Protocols --> Virtualbox;

Are you saying that it does not (not sure I understand this one).

• if necessary have another (new) configuration to control this behaviour.

Sure, what would this flag/option do?

May I suggest another option?
I think it may just be easier to:

• still initialize the vbox sessions, but do it in the background, without preventing this from completing winswitch startup
• group all those vbox sessions under a submenu (would a threshold of 10 items work?)

Or:

• maybe it would help to differentiate the sessions if their icon had the session type overlayed in the corner? (ie: the virtualbox icon would cover about a quarter of the icon for each vbox session)

I tried to modify the code responsible for creation of
~/.winswitch/server/protocols/virtualbox.conf
with "enabled=True" but couldn't find how it is done.

self.enabled = True
is set in the superclass and the code just serializes the class's fields to file.
It's not immediately obvious but there are docstrings in the superclass for this.

[onlyjob]

• not initialise VBOX sessions by default;

ok, but how would you initialize them?

Perhaps the best would be to list them as menu somehow distinguishing running ones from powered off.
I'm not sure regarding particular implementation, sorry.

• obey existing Configuration --> Protocols --> Virtualbox;

Are you saying that it does not (not sure I understand this one).

When I run Winswitch for the first time and disable the above option,
on second run I still have VBOX sessions initialised for embedded local server.

I even tried to patch winswitch/objects/user_base.py:
-self.supports_virtualbox = True
+self.supports_virtualbox = False

but first run still create VBOXes in embedded local server.

I'm not sure if this is working as expected.

• if necessary have another (new) configuration to control this behaviour.

Sure, what would this flag/option do?

Control "enabled=(False|True)" setting defined in ~/.winswitch/server/protocols/virtualbox.conf
from GUI.

May I suggest another option?
I think it may just be easier to:

• still initialize the vbox sessions, but do it in the background, without preventing this from completing winswitch startup

IMHO this is not that important as long as user can control whenever she/he wants VBOX sessions.

• group all those vbox sessions under a submenu (would a threshold of 10 items work?)

That would be great.

Or:

• maybe it would help to differentiate the sessions if their icon had the session type overlayed in the corner? (ie: the virtualbox icon would cover about a quarter of the icon for each vbox session)

I think this is not enough... Risk of accidental start would still be too high...

Frankly I didn't yet figured out how VBOX sessions can be useful at all...
For example I have one VM which is not booting. I accidentally started it by clicking on VBOX session menu item - it's started to boot and crashed. Now I couldn't terminate it at all without opening shell to machine where it's started.

If I wanted a remote VirtualBox? session I would probably just export VirtualBox? GUI itself - this way I would at least have control over VM like snapshots manipulation, start/stop, installing guest additions etc.

I tried to modify the code responsible for creation of
~/.winswitch/server/protocols/virtualbox.conf
with "enabled=True" but couldn't find how it is done.

self.enabled = True
is set in the superclass and the code just serializes the class's fields to file.
It's not immediately obvious but there are docstrings in the superclass for this.

Please forgive my ignorance buy I didn't understand a thing from this explanation.... (I'm not a Python developer)
Could you please kindly advise which file you're talking about and possibly line numbers or any whereabouts inside the file if you could?

Thanks.

Regards,
Dmitry.

[Antoine Martin]

As of r4939, you can start winswitch with:

winswitch_applet --no-virtualbox

Or:

winswitch_server --no-xpra

("--no-XXXX" you get the idea)
And the initial configuration will have enabled=False for this particular protocol.
As of r4940, this switch also overrides the config file if it exists.

Is this solution good enough for you?

---

FYI: user_base.py is the superclass for users, not servers.
And even then, lying about what is and isn't supported isn't the best approach.

---

I also checked the "initialize in the background" idea and it was already the case (I had forgotten).

[onlyjob]

Thank you but I think it is still not good enough.

Probably in most cases winswitch_applet would be started from menu entry which makes '--no-virtualbox' not very useful. I believe this should be default.

Virtualbox is the only protocol that I think is worth disabling - why on earth one would ever want to disable xpra?

I tried r4944 and local server still populate all configured VMs and still there is no way to prevent this from GUI (no relevant configuration option).

I consider this as a major usability issue and frankly a dangerous one. Please excuse me if I repeat myself but I have only enough RAM to start two or maybe even one VM when I have other applications running.

If I use normal VirtualBox? interface I never have problems to say which VM is started so I have a chance to stop running VM(s) if I need another one.
Winswitch is very dangerously misleading about running VMs.

Winswitch allows me to cripple my system by starting VM accidentally with one click because starting VM and connecting toalready running VM is the very same operation. Ideally there are should be no sessions for inactive VMs in first place.

To me VBOX support seems so superfluous that it is actually undermines the usefulness of winswith, otherwise wonderful application.

What are the Pros of running VMs using winswitch VBOX protocol comparing to running a normal VirtualBox? GUI exported through xpra? I don't know any.

As for Cons - there are many. Besides the already mentioned issues let's say
I need to configure shared folders? Ops..
Mount CD image? Ops...
Pause VM? Ops...
Resize by dragging window edge? Ops...
Check which ones are already running? Ops...
Run full screen? Ops...
Configure NIC? Ops...

List can go on...
Meanwhile I can perfectly run VirtualBox? from winswitch menu and have no above problems whatsoever.

I will be very happy if I could disable VBOX protocol support by default and allow user to enable it from GUI if she/he wishes to have all the inconvenience.

At the moment this is my only concern for winswitch in Debian.

With current defaults I can't deploy winswitch to users who also have some VirtualBox? VMs without editing their settings in ~/.winswitch/server/protocols/virtualbox.conf

I hope you understand the problem.

Thank you.

Best regards,
Dmitry.

[onlyjob]

In a way --no-virtualbox option is already immensely helpful. Now I can patch .desktop file and use the package to deploy winswitch safely. But of course this doesn't solve the underlying issue.

Cheers,
Dmitry.

[Antoine Martin]

Patching the desktop file to add --no-virtualbox is enough for those that do not want it. Closing.

---

As for the usefulness of this support, let's just say that we will have to agree to disagree. The behaviour is very different: one uses virtualbox's built-in VNC support (which can be used together with the regular window UI), the other uses whatever session type you use to start the VirtualBox window UI (nx, xpra, ssh..)

---

I have recorded the requirement for making the distinction between stopped sessions and suspended/running ones in #176

[onlyjob]

I think we can agree that generally features are good, if implemented safely and intuitively. More features means more freedom to choose from and freedom is good. I wouldn't mind VBOX support if it wouldn't be as annoying as it is now.

Patching .desktop file due to bad defaults and lack of GUI control over the controversial feature is the only viable solution now.
I only wish it would be a bit better but it will do for now.

Anyway thank you for responding so promptly and I do appreciate that you provided a solution - perhaps not a perfect but certainly working one.

Many thanks and big respect to your work.