Shutdown/suspend inactive VMs #832

marmarek · Mar 8, 2015

Reported by joanna on 27 Apr 2014 12:29 UTC
If a VM is open but not "active" for some time (e.g. 1h) then we might consider pausing/suspending it to save on resources (RAM in case of laptop, etc).

The specific action (suspend, pause, etc) should be VMM-specific.

Migrated-From: https://wiki.qubes-os.org/ticket/832

Comment by marmarek on 27 Apr 2014 21:00 UTC
What is "inactive" VM? That UsbVM running in the background without any active window, but serving some block devices to other VMs?

But ok, some VMs (all AppVMs by default?) can be selected for such mechanism.

Perhaps if "inactive" means "without any visible window" (no user application is running), the VM can be simply shut off. VM startup (especially Linux) is rather fast.
For Xen case, alternatives are problematic:

pause do not release memory
suspend (save state to disk) do not work for all cases - some VMs (>=4GB RAM, >1CPU) crashes after resume

marmarek · Mar 8, 2015

Comment by marmarek on 27 Apr 2014 21:00 UTC
What is "inactive" VM? That UsbVM running in the background without any active window, but serving some block devices to other VMs?

But ok, some VMs (all AppVMs by default?) can be selected for such mechanism.

Perhaps if "inactive" means "without any visible window" (no user application is running), the VM can be simply shut off. VM startup (especially Linux) is rather fast.
For Xen case, alternatives are problematic:

pause do not release memory
suspend (save state to disk) do not work for all cases - some VMs (>=4GB RAM, >1CPU) crashes after resume

I think that such VM can be also shut down. This would be especially useful if there is low free RAM. But I agree that the largest issue now is determining if the VM is active.

I hope that detection by no active window (or systray icon or something like it) will work for most VMs. At the start, it can be opt-in, so users wanting the feature (like me) would enable it maybe in all VMs except sys-firewall and USBVM and some similar VMs. (Note that even sys-net has systray icon by default.)

v6ak · May 7, 2015

I think that such VM can be also shut down. This would be especially useful if there is low free RAM. But I agree that the largest issue now is determining if the VM is active.

I hope that detection by no active window (or systray icon or something like it) will work for most VMs. At the start, it can be opt-in, so users wanting the feature (like me) would enable it maybe in all VMs except sys-firewall and USBVM and some similar VMs. (Note that even sys-net has systray icon by default.)

If listing active windows would be enough, it should be simple to write
a script which will periodically iterate over windows and shutdown VMs
with no windows (after some time). You can use for example xdotool for
that:

xdotool search --class <VMNAME>

I'm not sure why, but it looks like there is always at least one window,
with default title VMapp command, so probably you can check if there
are at least two windows - and if not (for some time) - shutdown the VM.
If you issue simple qvm-shutdown it will refuse to stop NetVM/ProxyVM
used by some other VMs, so this case will be covered automatically.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · May 11, 2015

If listing active windows would be enough, it should be simple to write
a script which will periodically iterate over windows and shutdown VMs
with no windows (after some time). You can use for example xdotool for
that:

xdotool search --class <VMNAME>

I'm not sure why, but it looks like there is always at least one window,
with default title VMapp command, so probably you can check if there
are at least two windows - and if not (for some time) - shutdown the VM.
If you issue simple qvm-shutdown it will refuse to stop NetVM/ProxyVM
used by some other VMs, so this case will be covered automatically.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

I don't see the windows for some apps. There are some hidden windows with unknown purpose, but they can be excluded by --onlyvisible.

I've hacked a bash script for this purpose. Creating a simple working script is easy. Handling some edge cases, especially race conditions, requires some tight cooperation with qragent. There is the script with my more detailed notes about challenges: https://github.com/v6ak/qubes-vm-autoshutdown I hope you will find it useful.

If something is unclear, do not hesitate to ask.

v6ak · May 15, 2015

I don't see the windows for some apps. There are some hidden windows with unknown purpose, but they can be excluded by --onlyvisible.

I've hacked a bash script for this purpose. Creating a simple working script is easy. Handling some edge cases, especially race conditions, requires some tight cooperation with qragent. There is the script with my more detailed notes about challenges: https://github.com/v6ak/qubes-vm-autoshutdown I hope you will find it useful.

If something is unclear, do not hesitate to ask.

I haven't implemented automatic pause, only automatic shutdown. If everything is implemented well, the automatic pause should not be needed, because inactive VM should consume almost no CPU. Moreover, a paused VM can't return any memory to Dom0 without unpausing, so pausing a VM with good memory conditions might cause worse memory conditions later. This could be improved, but it should be a separate issue.

v6ak · May 15, 2015

I haven't implemented automatic pause, only automatic shutdown. If everything is implemented well, the automatic pause should not be needed, because inactive VM should consume almost no CPU. Moreover, a paused VM can't return any memory to Dom0 without unpausing, so pausing a VM with good memory conditions might cause worse memory conditions later. This could be improved, but it should be a separate issue.

So, my approach with --onlyvisible does not work correctly when using multiple Activities (or possibly virtual desktops or maybe minimized windows), as it excludes these windows… Statusbar icons are also often invisible when using autohide. I'll try to fix that by excluding the VMapp commands, but I feel this like a hack.

v6ak · May 25, 2015

So, my approach with --onlyvisible does not work correctly when using multiple Activities (or possibly virtual desktops or maybe minimized windows), as it excludes these windows… Statusbar icons are also often invisible when using autohide. I'll try to fix that by excluding the VMapp commands, but I feel this like a hack.

Maybe you can enumerate the windows inside the VM - it looks to be not
affected by switching to another desktop.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · May 25, 2015

Maybe you can enumerate the windows inside the VM - it looks to be not
affected by switching to another desktop.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Hmm, actually the whole script can run inside VM - check if there are
some windows, and if not (for some time), then shutdown itself. It would
be trivial to enable it only for some VMs (using qvm-service framework).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · May 25, 2015

Hmm, actually the whole script can run inside VM - check if there are
some windows, and if not (for some time), then shutdown itself. It would
be trivial to enable it only for some VMs (using qvm-service framework).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

It seems to bring more issues than solves. First, it requires xdotool having installed on all such VMs, but that might be OK. However, maybe delegating strategy for “Am I active?” to particular VMs would be cleaner than checking it from dom0. But while I get rid of “VMapp command” windows, I get some windows like this one (slightly modified xprop dump):

AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-asdfghjkl;,guid=0123456789abcdef0123456789abcdef"
PULSE_COOKIE(STRING) = "01234567890…………
PULSE_SERVER(STRING) = "{01234567890abcdef…}unix:/run/user/1000/pulse/native"
PULSE_SESSION_ID(STRING) = "c1"
PULSE_ID(STRING) = "1000@01234567890abcdef…/815"
RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.lcdfilter:\tlcddefault\nXft.rgba:\trgb\n"
_NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_MOVERESIZE, _NET_WM_STATE, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_DEMANDS_ATTENTION
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x200002
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""
XFree86_has_VT(INTEGER) = 1
XFree86_VT(INTEGER) = 7
VFB_IDENT(STRING) = "TRUE"

Maybe there is something that tells us that the window is unused. If so, it would be cleaner to blacklist these windows than to blacklist some windows based on their title.

v6ak · May 25, 2015

It seems to bring more issues than solves. First, it requires xdotool having installed on all such VMs, but that might be OK. However, maybe delegating strategy for “Am I active?” to particular VMs would be cleaner than checking it from dom0. But while I get rid of “VMapp command” windows, I get some windows like this one (slightly modified xprop dump):

AT_SPI_BUS(STRING) = "unix:abstract=/tmp/dbus-asdfghjkl;,guid=0123456789abcdef0123456789abcdef"
PULSE_COOKIE(STRING) = "01234567890…………
PULSE_SERVER(STRING) = "{01234567890abcdef…}unix:/run/user/1000/pulse/native"
PULSE_SESSION_ID(STRING) = "c1"
PULSE_ID(STRING) = "1000@01234567890abcdef…/815"
RESOURCE_MANAGER(STRING) = "*customization:\t-color\nXft.antialias:\t1\nXft.hinting:\t1\nXft.hintstyle:\thintslight\nXft.lcdfilter:\tlcddefault\nXft.rgba:\trgb\n"
_NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_MOVERESIZE, _NET_WM_STATE, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_DEMANDS_ATTENTION
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x200002
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""
XFree86_has_VT(INTEGER) = 1
XFree86_VT(INTEGER) = 7
VFB_IDENT(STRING) = "TRUE"

Maybe there is something that tells us that the window is unused. If so, it would be cleaner to blacklist these windows than to blacklist some windows based on their title.

Isn't this root window? When I execute xdotool search --onlyvisible ., I get only real application windows. Some applications are even
exposing last user activity time in _NET_WM_USER_TIME property.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · May 25, 2015

Isn't this root window? When I execute xdotool search --onlyvisible ., I get only real application windows. Some applications are even
exposing last user activity time in _NET_WM_USER_TIME property.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

It may be something like that, I am not sure. But I see that “window” even with --onlyvisible, just after the VM start. It might be some difference between Fedora and Debian (tested with Jessie).

I've, however tested that windows are considered in AppVM as “visible” even if they are minimized. When I call xdotool windowminimize in the AppVM for a window, it is just ignored and the window is still “visible”. that's good for implementing reporting activity status from the AppVM itself, but I am not sure if I can rely on it.

v6ak · May 25, 2015

It may be something like that, I am not sure. But I see that “window” even with --onlyvisible, just after the VM start. It might be some difference between Fedora and Debian (tested with Jessie).

I've, however tested that windows are considered in AppVM as “visible” even if they are minimized. When I call xdotool windowminimize in the AppVM for a window, it is just ignored and the window is still “visible”. that's good for implementing reporting activity status from the AppVM itself, but I am not sure if I can rely on it.

I think this is a possible usability issue. One would wonder if one detached a job (& disown), closed the console window, and later the VM was shut down, therefore the job unexpectedly interrupted, just because it had no more graphical applications running. Or if that VM was running a server service or whatever else background processes one might run. If you want to implement this, please have a checkbox in QVMM something along the lines of "automatically shut down VM when there is no more graphical windows for 1 hour".

adrelanos · Nov 4, 2015

I think this is a possible usability issue. One would wonder if one detached a job (& disown), closed the console window, and later the VM was shut down, therefore the job unexpectedly interrupted, just because it had no more graphical applications running. Or if that VM was running a server service or whatever else background processes one might run. If you want to implement this, please have a checkbox in QVMM something along the lines of "automatically shut down VM when there is no more graphical windows for 1 hour".

Hrm, I wonder if from a usability standpoint, we might want to ask the user to decide when certain criteria is met, for instance:

If VM has not been used in 30 minutes AND it DOES NOT have background services running
2: Prompt user with passive tray notification "Want to put the VM 'Work' to sleep? It looks like you haven't used it in awhile"
Offer buttons [Don't Ask Again] [Yes]

That way a user can use their brain to determine "no, I have some sort of thing going on in that VM" or "I need to toggle back to it once I finish task in other VM"

bnvk · Nov 21, 2015

Hrm, I wonder if from a usability standpoint, we might want to ask the user to decide when certain criteria is met, for instance:

If VM has not been used in 30 minutes AND it DOES NOT have background services running
2: Prompt user with passive tray notification "Want to put the VM 'Work' to sleep? It looks like you haven't used it in awhile"
Offer buttons [Don't Ask Again] [Yes]

That way a user can use their brain to determine "no, I have some sort of thing going on in that VM" or "I need to toggle back to it once I finish task in other VM"

If you must add this, I suggest another IF.

If there is actually need to save RAM. When there is still enough free RAM, don't bother asking for optimizing.

That would be dialogs popping out of nowhere interrupting whatever the user is currently doing. And 4 inactive VMs (ex: vault, social, bank, private) would result in 4 such dialogs. So I guess these notifications should be accumulated into a single dialog. [or less optimal, be in a queue, not all pop up at the same time]

Another perhaps good place (maybe not for the first, but second iteration of this) might be the global Qubes [security] status systray icon. Instead of "green" it could perhaps still glow "green" but with a small additional info symbol. And once users are curios and click it, this VM shutdown questions are shown.

adrelanos · Nov 21, 2015

If you must add this, I suggest another IF.

If there is actually need to save RAM. When there is still enough free RAM, don't bother asking for optimizing.

That would be dialogs popping out of nowhere interrupting whatever the user is currently doing. And 4 inactive VMs (ex: vault, social, bank, private) would result in 4 such dialogs. So I guess these notifications should be accumulated into a single dialog. [or less optimal, be in a queue, not all pop up at the same time]

Another perhaps good place (maybe not for the first, but second iteration of this) might be the global Qubes [security] status systray icon. Instead of "green" it could perhaps still glow "green" but with a small additional info symbol. And once users are curios and click it, this VM shutdown questions are shown.

If VM has not been used in 30 minutes AND it DOES NOT have background services running

Actually it is really tricky to check for background services. Every
Linux system have some background services and it isn't obvious which
are actually used by the user.

If there is actually need to save RAM. When there is still enough free RAM, don't bother asking for optimizing.

I don't think it's necessary. Even if not for RAM saving, shutting down
unused VMs will lower CPU usage -> more battery time.

I think it's better to have this feature being optional. So it can be
for example enabled for VM used only for web browser, but disabled for
VPN VM, printing VM etc.
We can start with opt-in approach, then decide about some other
defaults.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Nov 21, 2015

If VM has not been used in 30 minutes AND it DOES NOT have background services running

Actually it is really tricky to check for background services. Every
Linux system have some background services and it isn't obvious which
are actually used by the user.

If there is actually need to save RAM. When there is still enough free RAM, don't bother asking for optimizing.

I don't think it's necessary. Even if not for RAM saving, shutting down
unused VMs will lower CPU usage -> more battery time.

I think it's better to have this feature being optional. So it can be
for example enabled for VM used only for web browser, but disabled for
VPN VM, printing VM etc.
We can start with opt-in approach, then decide about some other
defaults.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Sounds good to me!

adrelanos · Nov 22, 2015

Sounds good to me!

I don't think that unused VMs consume considerable amount of power. They, however, consume some RAM which could be used for caches and so on.

If VM pausing will be implemented, it would be useful if RAM footprint is reduced before the pause, because the paused VM can't participate in memory balancing. Without this, paused VM could have worse effect on amount of available RAM than a running VM. I am not sure if pausing will be a simple task.

There might be some grey zone. Consider a VM with tasks or calendar. When I minimize it, I don't need it and it might be shut down (like in Android). However, this will work better after some raise-or-run mechanism is implemented.

I will probably have some motivation for improving the script (mainly offloading the “active VM” strategy from dom0 to domU) soon, because I'll have to downgrade my RAM due to some RAM failure…

v6ak · Nov 23, 2015

I don't think that unused VMs consume considerable amount of power. They, however, consume some RAM which could be used for caches and so on.

If VM pausing will be implemented, it would be useful if RAM footprint is reduced before the pause, because the paused VM can't participate in memory balancing. Without this, paused VM could have worse effect on amount of available RAM than a running VM. I am not sure if pausing will be a simple task.

There might be some grey zone. Consider a VM with tasks or calendar. When I minimize it, I don't need it and it might be shut down (like in Android). However, this will work better after some raise-or-run mechanism is implemented.

I will probably have some motivation for improving the script (mainly offloading the “active VM” strategy from dom0 to domU) soon, because I'll have to downgrade my RAM due to some RAM failure…

Actually this task (as in description) is about shutting down the VMs (or some other means of releasing RAM). Updated title to less confusing.

marmarek · Nov 23, 2015

Actually this task (as in description) is about shutting down the VMs (or some other means of releasing RAM). Updated title to less confusing.

I see both options, suspend and shutdown. (I am actually not sure if suspend is something different from pause.) I have commented something about chalenges of VM suspending, but I am not going to implement it, at least not now. I will rather implement the autoshutdown, because it is simpler to implement and it IMHO gives more benefit.

v6ak · Nov 23, 2015

I see both options, suspend and shutdown. (I am actually not sure if suspend is something different from pause.) I have commented something about chalenges of VM suspending, but I am not going to implement it, at least not now. I will rather implement the autoshutdown, because it is simpler to implement and it IMHO gives more benefit.

Yes, in case of Xen (we don't have other cases right now ;) ), probably the easiest and most beneficial way would be to shutdown unused VMs.

marmarek · Nov 23, 2015

Yes, in case of Xen (we don't have other cases right now ;) ), probably the easiest and most beneficial way would be to shutdown unused VMs.

Hmm, I can call RPC from domU… But, is there any way to call it from dom0? I haven't found it at https://www.qubes-os.org/doc/qrexec3/ .

However, this brings me some idea: The design might be reversed: AppVMs would inform dom0 about being unused. Any call of RPC would clear the unused flag and the AppVM would have to send it again (if desired).

v6ak · Nov 28, 2015

Hmm, I can call RPC from domU… But, is there any way to call it from dom0? I haven't found it at https://www.qubes-os.org/doc/qrexec3/ .

However, this brings me some idea: The design might be reversed: AppVMs would inform dom0 about being unused. Any call of RPC would clear the unused flag and the AppVM would have to send it again (if desired).

On Sat, Nov 28, 2015 at 06:35:59AM -0800, Vít Šesták wrote:

Hmm, I can call RPC from domU… But, is there any way to call it from dom0? I haven't found it at https://www.qubes-os.org/doc/qrexec3/ .

Not a nice API, but you can call RPC with:

qvm-run -p some-vm 'QUBESRPC name-of-service dom0'

However, this brings me some idea: The design might be reversed: AppVMs would inform dom0 about being unused. Any call of RPC would clear the unused flag and the AppVM would have to send it again (if desired).

What about simply shutting down unused VM from within?
So you would have a service in VM (enabled/disabled by qvm-service
framework[1]), which checks if the VM is unused for some configured time
period. And if so, simply call poweroff.

[1] https://www.qubes-os.org/doc/qubes-service/

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Nov 28, 2015

On Sat, Nov 28, 2015 at 06:35:59AM -0800, Vít Šesták wrote:

Hmm, I can call RPC from domU… But, is there any way to call it from dom0? I haven't found it at https://www.qubes-os.org/doc/qrexec3/ .

Not a nice API, but you can call RPC with:

qvm-run -p some-vm 'QUBESRPC name-of-service dom0'

However, this brings me some idea: The design might be reversed: AppVMs would inform dom0 about being unused. Any call of RPC would clear the unused flag and the AppVM would have to send it again (if desired).

What about simply shutting down unused VM from within?
So you would have a service in VM (enabled/disabled by qvm-service
framework[1]), which checks if the VM is unused for some configured time
period. And if so, simply call poweroff.

[1] https://www.qubes-os.org/doc/qubes-service/

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Would an easier way to do this just be to have a setting in a VM's VM Settings that says: "Shutdown VM when Applications Are Closed", which in practice is just "Open Applications as Disposable VMs".

That way for your single-use VMs like vault, when you close keepassx it will shut down the VM as well.

mfc · Dec 3, 2015

Would an easier way to do this just be to have a setting in a VM's VM Settings that says: "Shutdown VM when Applications Are Closed", which in practice is just "Open Applications as Disposable VMs".

That way for your single-use VMs like vault, when you close keepassx it will shut down the VM as well.

It's a very limited choice to have: Run one app that shuts down the vm when it quits, or shutdown the vm the regular way.

I'd rather be able to run several apps in a vm, then decide which one I'll quit last. Have a modifier key like Shift work with the window close widget, to let the user indicate 'shutdown now' at the same time they close the app window. Even if you pop-up an "Are you sure?" dialog (which defaults to "Yes"), its still much more convenient than the usual QM interaction.

tasket · Jul 4, 2016

It's a very limited choice to have: Run one app that shuts down the vm when it quits, or shutdown the vm the regular way.

I'd rather be able to run several apps in a vm, then decide which one I'll quit last. Have a modifier key like Shift work with the window close widget, to let the user indicate 'shutdown now' at the same time they close the app window. Even if you pop-up an "Are you sure?" dialog (which defaults to "Yes"), its still much more convenient than the usual QM interaction.

It's a very limited choice to have: Run one app that shuts down the vm when it quits, or shutdown the vm the regular way.

This is not what I've meant - I was talking about a simple service which will check if there is any application (defined as: something with visible window) running. If there is none (for at least X minutes), shutdown the VM. There is no selected application which will shutdown the VM when closed. You can think of it like "VM will shutdown automatically after last application is closed".

The whole mechanism makes sense only for AppVMs, but for example not for ProxyVMs, which are needed even without any applications (visible windows) running. But that's an easy part.

marmarek · Jul 4, 2016

It's a very limited choice to have: Run one app that shuts down the vm when it quits, or shutdown the vm the regular way.

This is not what I've meant - I was talking about a simple service which will check if there is any application (defined as: something with visible window) running. If there is none (for at least X minutes), shutdown the VM. There is no selected application which will shutdown the VM when closed. You can think of it like "VM will shutdown automatically after last application is closed".

The whole mechanism makes sense only for AppVMs, but for example not for ProxyVMs, which are needed even without any applications (visible windows) running. But that's an easy part.

I was responding more to mfc's suggestion to use dispvm as a model... Sorry I wasn't clear. The goal of getting unused vms out of memory needs consideration of alternatives, and I'm not sure I like the idea of a fully automatic approach because the risk of having vms restart too often for the users' taste (or hobbling their workflow) is a factor.

Hinging the feature on some easy indication of intent from the user may be the way to go. Even in Mac OSX, apps usually stay around until the user hits cmd-q or a quit command from mouse (manual input). The reason they can do this is swap space (which is automatic) allowing the system to compensate for a 'lazy' user who rarely quits apps. That suggests Apple arrived at a balance that avoids hampering app availability or making the user wait too much. But in Qubes' case its more a question of VM availability, esp. since the user is conditioned to be intensely vm-conscious. Unfortunately, the penalties for re-loading (restarting) vms more often are greater in Qubes than restarting apps in regular OS, and QM doesn't function like a dock anyway (I realize this touches on Joanna's idea in #2132).

Its also helpful to think of some particular use cases and apps which are impacted by such a feature. The user leaving a messaging/voip client running, for instance: They might not leave a window open and activity would be nonexistent... until someone calls and the user expects the app to react. There are probably numerous others we can't anticipate, which is why I'm echoing @bnvk 's concern about user input.

Here are good options (IMHO) from UX standpoint:

Combine marek's and mfc's ideas so that vms continue hanging around by default. But have a prefs setting the user can enable which says: "shutdown vm when app windows are gone". You could place it right below the 'Start vm automatically on boot' option. This makes the feature act on the user's intent, even if its not on a session-by-session basis. It also employs the principle of sensible defaults.
Overloading one of the titlebar widgets with a modifier key; holding the modifier while clicking the close widget means "shutdown the vm, too". Further, since baremetal UIs have hotkeys for shutting the system down (ctrl-alt-shift-pgdn in KDE), we could also have a shutdown-vm hotkey that works similar to the widget; I wonder if ctrl-shift-q is appropriate. This is both very convenient and flexible as the user can do this extremely quickly each time they are exiting an app.
Make QM functions easier to access (e.g. in a panel of basic vm functions). To me, this suggests mirroring the relationship between the task bar and the task manager in classic desktops.
Increase the 'swappiness' of the vms. This is how Windows deals with large runtime environments, and appvms are like really hefty REs.

...or a combination of the above.

What I don't like is making an automatic assumption based on appvm / servicevm status; at least not in this case. I also don't think we should be adding pop-up questions that the user didn't immediately initiate (e.g. based on a timer); even if I enabled that feature myself, it would get annoying.

tasket · Jul 5, 2016

I was responding more to mfc's suggestion to use dispvm as a model... Sorry I wasn't clear. The goal of getting unused vms out of memory needs consideration of alternatives, and I'm not sure I like the idea of a fully automatic approach because the risk of having vms restart too often for the users' taste (or hobbling their workflow) is a factor.

Hinging the feature on some easy indication of intent from the user may be the way to go. Even in Mac OSX, apps usually stay around until the user hits cmd-q or a quit command from mouse (manual input). The reason they can do this is swap space (which is automatic) allowing the system to compensate for a 'lazy' user who rarely quits apps. That suggests Apple arrived at a balance that avoids hampering app availability or making the user wait too much. But in Qubes' case its more a question of VM availability, esp. since the user is conditioned to be intensely vm-conscious. Unfortunately, the penalties for re-loading (restarting) vms more often are greater in Qubes than restarting apps in regular OS, and QM doesn't function like a dock anyway (I realize this touches on Joanna's idea in #2132).

Its also helpful to think of some particular use cases and apps which are impacted by such a feature. The user leaving a messaging/voip client running, for instance: They might not leave a window open and activity would be nonexistent... until someone calls and the user expects the app to react. There are probably numerous others we can't anticipate, which is why I'm echoing @bnvk 's concern about user input.

Here are good options (IMHO) from UX standpoint:

Combine marek's and mfc's ideas so that vms continue hanging around by default. But have a prefs setting the user can enable which says: "shutdown vm when app windows are gone". You could place it right below the 'Start vm automatically on boot' option. This makes the feature act on the user's intent, even if its not on a session-by-session basis. It also employs the principle of sensible defaults.
Overloading one of the titlebar widgets with a modifier key; holding the modifier while clicking the close widget means "shutdown the vm, too". Further, since baremetal UIs have hotkeys for shutting the system down (ctrl-alt-shift-pgdn in KDE), we could also have a shutdown-vm hotkey that works similar to the widget; I wonder if ctrl-shift-q is appropriate. This is both very convenient and flexible as the user can do this extremely quickly each time they are exiting an app.
Make QM functions easier to access (e.g. in a panel of basic vm functions). To me, this suggests mirroring the relationship between the task bar and the task manager in classic desktops.
Increase the 'swappiness' of the vms. This is how Windows deals with large runtime environments, and appvms are like really hefty REs.

...or a combination of the above.

What I don't like is making an automatic assumption based on appvm / servicevm status; at least not in this case. I also don't think we should be adding pop-up questions that the user didn't immediately initiate (e.g. based on a timer); even if I enabled that feature myself, it would get annoying.

On Mon, Jul 04, 2016 at 10:58:19PM -0700, ttasket wrote:

Combine marek's and mfc's ideas so that vms continue hanging around by default. But have a prefs setting the user can enable which says: "shutdown vm when app windows are gone". You could place it right below the 'Start vm automatically on boot' option. This makes the feature act on the user's intent, even if its not on a session-by-session basis. It also employs the principle of sensible defaults.

This one :)

And the switch can be (technically) a simple entry in qvm-service
(services tab in VM settings). Then can be also exposed as some more
visible option in Qubes Manager.

Increase the 'swappiness' of the vms. This is how Windows deals with large runtime environments, and appvms are like really hefty REs.

IMHO hard to do it right. To not affect currently running (used)
applications - for example firefox using a lot of memory...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

marmarek · Jul 5, 2016

On Mon, Jul 04, 2016 at 10:58:19PM -0700, ttasket wrote:

Combine marek's and mfc's ideas so that vms continue hanging around by default. But have a prefs setting the user can enable which says: "shutdown vm when app windows are gone". You could place it right below the 'Start vm automatically on boot' option. This makes the feature act on the user's intent, even if its not on a session-by-session basis. It also employs the principle of sensible defaults.

This one :)

And the switch can be (technically) a simple entry in qvm-service
(services tab in VM settings). Then can be also exposed as some more
visible option in Qubes Manager.

Increase the 'swappiness' of the vms. This is how Windows deals with large runtime environments, and appvms are like really hefty REs.

IMHO hard to do it right. To not affect currently running (used)
applications - for example firefox using a lot of memory...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

PoC here: https://gist.github.com/marmarek/21744f11c091f8deb0179a44b26a9b4d
Currently it only print "idle!!!!!" when it would shutdown the VM. This require a lot of testing. So, I think further steps should be:

package it, but keep as opt-in (using qvm-service for enabling)
let people test it - I expect various corner cases, like the one with IM @tasket mentioned above
after collecting enough feedback, consider enabling it by default (or not) again, based on collected information

The current version have timeout set to 5min.

marmarek · Dec 21, 2016

PoC here: https://gist.github.com/marmarek/21744f11c091f8deb0179a44b26a9b4d
Currently it only print "idle!!!!!" when it would shutdown the VM. This require a lot of testing. So, I think further steps should be:

package it, but keep as opt-in (using qvm-service for enabling)
let people test it - I expect various corner cases, like the one with IM @tasket mentioned above
after collecting enough feedback, consider enabling it by default (or not) again, based on collected information

The current version have timeout set to 5min.

Posting a comment I made on the list because it makes sense here. I don't think its worth the effort to add a timer-based VM shutdown to Qubes...

I still prefer my #2 suggestion: If apps shutdown with a Ctrl+Q shortcut, then a Ctrl+Alt+Q or similar shortcut to shutdown the VM would make a lot of sense.

When users start encountering VMs automatically shutdown as soon as they begin to switch back to them--even if on occassion--they'll disable the flag for automatic idle shutdown on all their VMs.

Even if they had set them manually to begin with, that means the modification to Qubes didn't help.

Think of a VM as a runtime environment. If Java or .Net automatically shutdown due to their running apps being idle, you would be sitting there right now wondering what these obscure "Java" and ".Net" thingies were. Its "very unorthodox", probably in the sense that its not going to help except in niche cases (like shutting down unused proxyVMs, which consume a lot less RAM to begin with).

tasket · Dec 21, 2016

Posting a comment I made on the list because it makes sense here. I don't think its worth the effort to add a timer-based VM shutdown to Qubes...

I still prefer my #2 suggestion: If apps shutdown with a Ctrl+Q shortcut, then a Ctrl+Alt+Q or similar shortcut to shutdown the VM would make a lot of sense.

When users start encountering VMs automatically shutdown as soon as they begin to switch back to them--even if on occassion--they'll disable the flag for automatic idle shutdown on all their VMs.

Even if they had set them manually to begin with, that means the modification to Qubes didn't help.

Think of a VM as a runtime environment. If Java or .Net automatically shutdown due to their running apps being idle, you would be sitting there right now wondering what these obscure "Java" and ".Net" thingies were. Its "very unorthodox", probably in the sense that its not going to help except in niche cases (like shutting down unused proxyVMs, which consume a lot less RAM to begin with).

When users start encountering VMs automatically shutdown as soon as they begin to switch back to them--even if on occassion--they'll disable the flag for automatic idle shutdown on all their VMs.

Why is this not solved by the combination of a delay before actually shutting down and having it off by default? It does match what I expect and want for many VMs.

jpouellet · Dec 21, 2016

When users start encountering VMs automatically shutdown as soon as they begin to switch back to them--even if on occassion--they'll disable the flag for automatic idle shutdown on all their VMs.

Why is this not solved by the combination of a delay before actually shutting down and having it off by default? It does match what I expect and want for many VMs.

Its not really "solved" so much as creating more complex behavior for the user to cope with. The user sets it, but its not "set and forget" because it has negative consequences. There will be times when workflow is interrupted because user wants to run app again in VM while VM is shutting down; There will also be more waiting for VM startup.

And there may be data loss in cases where the user didn't anticipate collision with background processes. Let's say, months after I set the Shutdown-On-Idle flag, I start a data transfer to the appVM using qvm-run, then I finish my text editing in same appVM and close the app. That's a problem. "Open window" does not map cleanly to "active runtime environment" it seems.

Anyway, I've stated my piece... I do hope if this gets implemented there will also be a shortcut key option at some point.

tasket · Dec 21, 2016

Its not really "solved" so much as creating more complex behavior for the user to cope with. The user sets it, but its not "set and forget" because it has negative consequences. There will be times when workflow is interrupted because user wants to run app again in VM while VM is shutting down; There will also be more waiting for VM startup.

And there may be data loss in cases where the user didn't anticipate collision with background processes. Let's say, months after I set the Shutdown-On-Idle flag, I start a data transfer to the appVM using qvm-run, then I finish my text editing in same appVM and close the app. That's a problem. "Open window" does not map cleanly to "active runtime environment" it seems.

Anyway, I've stated my piece... I do hope if this gets implemented there will also be a shortcut key option at some point.

And there may be data loss in cases where the user didn't anticipate collision with background processes. Let's say, months after I set the Shutdown-On-Idle flag, I start a data transfer to the appVM using qvm-run, then I finish my text editing in same appVM and close the app. That's a problem. "Open window" does not map cleanly to "active runtime environment" it seems.

IMHO "then do not enable auto-shutdown" is an acceptable response here. Manually disabling auto-sleep on OS X when you intend to have long-running background jobs seems to me an appropriate analogy. I have plenty of VMs where I would most definitely not ever run into that, and where auto-shutdown is desired. (banking, music playing, various *-testing VMs, various "hold this category of documents" VMs, etc.)

Anyway, I've stated my piece... I do hope if this gets implemented there will also be a shortcut key option at some point.

See my PoC here: https://gist.github.com/jpouellet/d57fb4e98ca3f5ad4ac0ec2596d18154

jpouellet · Dec 21, 2016

And there may be data loss in cases where the user didn't anticipate collision with background processes. Let's say, months after I set the Shutdown-On-Idle flag, I start a data transfer to the appVM using qvm-run, then I finish my text editing in same appVM and close the app. That's a problem. "Open window" does not map cleanly to "active runtime environment" it seems.

IMHO "then do not enable auto-shutdown" is an acceptable response here. Manually disabling auto-sleep on OS X when you intend to have long-running background jobs seems to me an appropriate analogy. I have plenty of VMs where I would most definitely not ever run into that, and where auto-shutdown is desired. (banking, music playing, various *-testing VMs, various "hold this category of documents" VMs, etc.)

Anyway, I've stated my piece... I do hope if this gets implemented there will also be a shortcut key option at some point.

See my PoC here: https://gist.github.com/jpouellet/d57fb4e98ca3f5ad4ac0ec2596d18154

Well, I'm not going to address points about "Its OK bc the user enabled it". That's not the measure of a quality feature.

Small PS--

Runtime environments usually shut themselves down when applications exit. This makes sense because those runtimes are intimately 'aware' of their apps. Dom0 window watching is a poor fit for this model. So based on that analogy, a timer-based shutdown would be best implemented within VMs perhaps as a Qubes service.

tasket · Dec 21, 2016

Well, I'm not going to address points about "Its OK bc the user enabled it". That's not the measure of a quality feature.

Small PS--

Runtime environments usually shut themselves down when applications exit. This makes sense because those runtimes are intimately 'aware' of their apps. Dom0 window watching is a poor fit for this model. So based on that analogy, a timer-based shutdown would be best implemented within VMs perhaps as a Qubes service.

a timer-based shutdown would be best implemented within VMs perhaps as a Qubes service.

Yes. This is exactly what @marmarek is proposing. His linked PoC watches for the absence of visible windows in the current X session - a condition reached within VMs when one is done with them and never to be sensibly reached in dom0.

jpouellet · Dec 21, 2016

a timer-based shutdown would be best implemented within VMs perhaps as a Qubes service.

Yes. This is exactly what @marmarek is proposing. His linked PoC watches for the absence of visible windows in the current X session - a condition reached within VMs when one is done with them and never to be sensibly reached in dom0.

[posting here, to not continue offtopic in the original thread]

On Wed, Dec 21, 2016 at 12:41:31PM -0500, Chris Laprise wrote: My proposal is simply to save the step of switching to QM... clicking on the small 'Q' in systray, looking through the screenful of VMs, click one, move mouse to toolbar or right-click-find-option-in-middle. Its annoying.

If you enable auto-shutdown, you wouldn't need to do it at all. In fact, ideally (after some tweaking its parameters), user would not need to worry about such implementation details like shutting down a VM. You want a web browser in untrusted qube? Just start it from the menu. You don't need it anymore? Simply close it. Just like on any other non-Qubes system. Having UX more uniform with "normal" system will lower the entry barrier. Without feature like this, I think every user get "not enough memory to start a VM" error message from time to time. Also note, that you don't need to enable this feature (or later - will be able to disable it), if you want. And use any other mechanism. AFAIR someone post on this ML a script to run a command in currently focused VM. Very similar thing could be used for this (just bind it to some key combo). And IMO such a tool could be even integrated into standard setup. But the default configuration should be as easy to use as possible (without decreasing security).

OTOH, I already know how to make my apps Save. I can press Ctrl+S in kate or Thunderbird before I use a combo like RControl+H to shutdown the VM--What VirtualBox uses. It allows me to get it done quickly and mindfully, without the aggravation of unintended shutdowns. Going further, the shutdown process could be made contingent on the currently-focused window closing. This makes sense, since the VM identity is derived from the window as well.

(...)

I guess I'm not comfortable with the idea of equating "open windows" with "running application". Its a stretch.

Yes, the algorithm may need some adjustments - this is why I've said it should be opt-in in the first stage. Proxy VM is the fist such example that come to my mind - it is "used" but do not have any visible window normally. Also note, as @jpouellet already noted - my solution is running inside a VM, and currently look for windows on VM local X server instance. But can be easily extended to watch for anything else too - like user processes or such.

But beyond that, I believe the occasional "UX Interruptus" of shutting down while user tries to run an app will lead most people who try it to eventually disable it.

This race condition is a fair point. It will need to be dealt with somehow.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

marmarek · Dec 22, 2016

[posting here, to not continue offtopic in the original thread]

On Wed, Dec 21, 2016 at 12:41:31PM -0500, Chris Laprise wrote: My proposal is simply to save the step of switching to QM... clicking on the small 'Q' in systray, looking through the screenful of VMs, click one, move mouse to toolbar or right-click-find-option-in-middle. Its annoying.

If you enable auto-shutdown, you wouldn't need to do it at all. In fact, ideally (after some tweaking its parameters), user would not need to worry about such implementation details like shutting down a VM. You want a web browser in untrusted qube? Just start it from the menu. You don't need it anymore? Simply close it. Just like on any other non-Qubes system. Having UX more uniform with "normal" system will lower the entry barrier. Without feature like this, I think every user get "not enough memory to start a VM" error message from time to time. Also note, that you don't need to enable this feature (or later - will be able to disable it), if you want. And use any other mechanism. AFAIR someone post on this ML a script to run a command in currently focused VM. Very similar thing could be used for this (just bind it to some key combo). And IMO such a tool could be even integrated into standard setup. But the default configuration should be as easy to use as possible (without decreasing security).

OTOH, I already know how to make my apps Save. I can press Ctrl+S in kate or Thunderbird before I use a combo like RControl+H to shutdown the VM--What VirtualBox uses. It allows me to get it done quickly and mindfully, without the aggravation of unintended shutdowns. Going further, the shutdown process could be made contingent on the currently-focused window closing. This makes sense, since the VM identity is derived from the window as well.

(...)

I guess I'm not comfortable with the idea of equating "open windows" with "running application". Its a stretch.

Yes, the algorithm may need some adjustments - this is why I've said it should be opt-in in the first stage. Proxy VM is the fist such example that come to my mind - it is "used" but do not have any visible window normally. Also note, as @jpouellet already noted - my solution is running inside a VM, and currently look for windows on VM local X server instance. But can be easily extended to watch for anything else too - like user processes or such.

But beyond that, I believe the occasional "UX Interruptus" of shutting down while user tries to run an app will lead most people who try it to eventually disable it.

This race condition is a fair point. It will need to be dealt with somehow.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

But beyond that, I believe the occasional "UX Interruptus" of shutting down while user tries to run an app will lead most people who try it to eventually disable it.

This race condition is a fair point. It will need to be dealt with somehow.

There are also other such races, for example trying to start an application in a given VM while it is still starting up. Only the first qvm-run when a VM is off will get wait for it to start up and then actually run it, subsequent attempts will just fail with Domain 'somevm': qrexec not connected..

jpouellet · Dec 22, 2016

But beyond that, I believe the occasional "UX Interruptus" of shutting down while user tries to run an app will lead most people who try it to eventually disable it.

This race condition is a fair point. It will need to be dealt with somehow.

There are also other such races, for example trying to start an application in a given VM while it is still starting up. Only the first qvm-run when a VM is off will get wait for it to start up and then actually run it, subsequent attempts will just fail with Domain 'somevm': qrexec not connected..

There are also other such races, for example trying to start an application in a given VM while it is still starting up. Only the first qvm-run when a VM is off will get wait for it to start up and then actually run it, subsequent attempts will just fail with Domain 'somevm': qrexec not connected..

That's right. It will be probably solved in Qubes 4.0 as a side effect. But we're talking here about not introducing another, rather annoying one.

marmarek · Dec 22, 2016

There are also other such races, for example trying to start an application in a given VM while it is still starting up. Only the first qvm-run when a VM is off will get wait for it to start up and then actually run it, subsequent attempts will just fail with Domain 'somevm': qrexec not connected..

That's right. It will be probably solved in Qubes 4.0 as a side effect. But we're talking here about not introducing another, rather annoying one.

I believe that there are two mutually exclusive approaches for VM: Full VM and seamless VM. Qubes uses mostly the latter, where automatic startup and shutdown makes much sense.

In my PoC, I use opened windows as a sign of inactivity. While this works most of the time, I agree this is not ideal solution. You can use the VM via qvm-run, qvm-copy-to-vm and so on, while there is no opened window. In some special cases, some server or synchronization can run in a VM on background without any GUI indication. Furthermore, there could be a race condition: 1. I try to start an application. 2. Application is starting, but does not show even a splashscreen yet. 3. Shutdown is initiated due to some inactivity. 4. Application would show some GUI if the shutdown was not initiated,

I believe all those issues can be solved, but it cannot be solved by a simple bash script that does not touch any Qubes internals. (I admit that this makes my PoC a dead end.) Actually, kind of such solution is already implemented for DVMs, though it is not as robust as we need for AppVMs:

Activity could be detected by existence of some ongoing RPC call. This could detect some cases like qvm-copy-to-vm and so on.
ProxyVMs and similar are easy case. Qubes even won't let you should them down without --force. But when no VM is connected, there is hardly some reason to keep them up.
Inactivity should be tracked by VM, at least partially. This would allow one to mark the VM as busy when having some server, sync or other background task running.
Existence of a window could be some last resort detection of activity.

Shutdown should be initiated by dom0, not by domU. This will allow some race conditions prevention and implement some other improvements:

After dom0 has initiated shutdown, it will know that it should not send any requests to a VM that is shutting down. This would prevent the race condition I mentioned.
Similar race conditions could be there with ProxyVMs.
Dom0 could have different strategies for inactive VMs based on memory situation and so on. When having enough memory, it could keep them on unless the template has been updated. When having low memory, it could turn some/all inactive VMs off in order to free some memory.
Qmemman could assign inactive VMs less extra memory. This could allow even suspending the inactive VMs without impact on memory. (Without assigning less memory, pausing inactive VMs when having much memory is bad, because paused VMs cannot give the assigned memory back.)
Qubes Manager could mark inactive VMs somewhat specially.

I know that implementing all of those ideas (even if you want to implement all of them) is far beyond MVP and I can't expect all of them in 4.0. But I believe they are good arguments to go this way.

Race condition when starting multiple apps in short interval is something quite different, but still related a bit. With autoshutdown, users are likely to hit such condition more frequently.

v6ak · Dec 22, 2016

I believe that there are two mutually exclusive approaches for VM: Full VM and seamless VM. Qubes uses mostly the latter, where automatic startup and shutdown makes much sense.

In my PoC, I use opened windows as a sign of inactivity. While this works most of the time, I agree this is not ideal solution. You can use the VM via qvm-run, qvm-copy-to-vm and so on, while there is no opened window. In some special cases, some server or synchronization can run in a VM on background without any GUI indication. Furthermore, there could be a race condition: 1. I try to start an application. 2. Application is starting, but does not show even a splashscreen yet. 3. Shutdown is initiated due to some inactivity. 4. Application would show some GUI if the shutdown was not initiated,

I believe all those issues can be solved, but it cannot be solved by a simple bash script that does not touch any Qubes internals. (I admit that this makes my PoC a dead end.) Actually, kind of such solution is already implemented for DVMs, though it is not as robust as we need for AppVMs:

Activity could be detected by existence of some ongoing RPC call. This could detect some cases like qvm-copy-to-vm and so on.
ProxyVMs and similar are easy case. Qubes even won't let you should them down without --force. But when no VM is connected, there is hardly some reason to keep them up.
Inactivity should be tracked by VM, at least partially. This would allow one to mark the VM as busy when having some server, sync or other background task running.
Existence of a window could be some last resort detection of activity.

Shutdown should be initiated by dom0, not by domU. This will allow some race conditions prevention and implement some other improvements:

After dom0 has initiated shutdown, it will know that it should not send any requests to a VM that is shutting down. This would prevent the race condition I mentioned.
Similar race conditions could be there with ProxyVMs.
Dom0 could have different strategies for inactive VMs based on memory situation and so on. When having enough memory, it could keep them on unless the template has been updated. When having low memory, it could turn some/all inactive VMs off in order to free some memory.
Qmemman could assign inactive VMs less extra memory. This could allow even suspending the inactive VMs without impact on memory. (Without assigning less memory, pausing inactive VMs when having much memory is bad, because paused VMs cannot give the assigned memory back.)
Qubes Manager could mark inactive VMs somewhat specially.

I know that implementing all of those ideas (even if you want to implement all of them) is far beyond MVP and I can't expect all of them in 4.0. But I believe they are good arguments to go this way.

Race condition when starting multiple apps in short interval is something quite different, but still related a bit. With autoshutdown, users are likely to hit such condition more frequently.

May I suggest naming and structuring the config options a certain way:

On naming, it would be best to avoid terms that suggest the system knows for certain that a VM is "idle". Instead name it according to criteria used (i.e. "no windows"), and make room for the user to select more than one type of criteria.

As qubes services, they could be named as a group:
qubes-autoshutdown-no-windows
qubes-autoshutdown-no-rpc
etc.

In a GUI grouping...

Auto-shutdown when:
- [ ] No windows are open
- [ ] Qubes rpc not in use

This has the positive effect of keeping the triggers for shutdown in full view; No assumptions will be made about a generic "idle" status that may not exist.

tasket · Dec 22, 2016

May I suggest naming and structuring the config options a certain way:

On naming, it would be best to avoid terms that suggest the system knows for certain that a VM is "idle". Instead name it according to criteria used (i.e. "no windows"), and make room for the user to select more than one type of criteria.

As qubes services, they could be named as a group:
qubes-autoshutdown-no-windows
qubes-autoshutdown-no-rpc
etc.

In a GUI grouping...

Auto-shutdown when:
- [ ] No windows are open
- [ ] Qubes rpc not in use

This has the positive effect of keeping the triggers for shutdown in full view; No assumptions will be made about a generic "idle" status that may not exist.

Well, this is something I disagree with. But this probably comes from different philosophical PoV. You probably look at a Qube more as a full-VM with some seamless features, while I look at a Qube as runtime environment that should be as seamless as possible. For me, a Qube being off or idle is just some subtle difference from end user view. In both cases, there is nothing really running. In both cases, the system should behave essentially the same.

A non-tech user (e.g. journalist) will not want to config anything, (s)he will want it to be working. I don't believe such user will run background tasks without any GUI, except those that are related to Qubes itself (e.g. file copy). Note that even IM applications show at least some systray icon. So, Qubes could handle all those cases automatically well. I believe that Qubes is also targeting those users.

A tech user that will break this assumption (e.g. me with some server running in a Qube) will be able to use some API to block the autoshutdown. Just creating, say, /rw/never-idle could be a very easy way to do so. Well, I admit that this is not a robust API that would allow multiple apps to inhibit the idle status, but even having such a rough (but easy) way to inhibit the autoshutdown would be great for many (most?) cases.

Why I believe it is better to configure this within the qube than from Qubes Manager: Imagine you apt install some app that needs this. With such API, it could configure the Qube without user interaction.

v6ak · Dec 22, 2016

Well, this is something I disagree with. But this probably comes from different philosophical PoV. You probably look at a Qube more as a full-VM with some seamless features, while I look at a Qube as runtime environment that should be as seamless as possible. For me, a Qube being off or idle is just some subtle difference from end user view. In both cases, there is nothing really running. In both cases, the system should behave essentially the same.

A non-tech user (e.g. journalist) will not want to config anything, (s)he will want it to be working. I don't believe such user will run background tasks without any GUI, except those that are related to Qubes itself (e.g. file copy). Note that even IM applications show at least some systray icon. So, Qubes could handle all those cases automatically well. I believe that Qubes is also targeting those users.

A tech user that will break this assumption (e.g. me with some server running in a Qube) will be able to use some API to block the autoshutdown. Just creating, say, /rw/never-idle could be a very easy way to do so. Well, I admit that this is not a robust API that would allow multiple apps to inhibit the idle status, but even having such a rough (but easy) way to inhibit the autoshutdown would be great for many (most?) cases.

Why I believe it is better to configure this within the qube than from Qubes Manager: Imagine you apt install some app that needs this. With such API, it could configure the Qube without user interaction.

A non-tech user (e.g. journalist) will not want to config anything, (s)he will want it to be working. I don't believe such user will run background tasks without any GUI, except those that are related to Qubes itself (e.g. file copy). Note that even IM applications show at least some systray icon. So, Qubes could handle all those cases automatically well. I believe that Qubes is also targeting those users.

@v6ak : Um, non-tech users have a way of finding functions in their GUI programs that do realize corner cases... such as processes that collect info or render projects in the background.

Suggesting to these--or any other--users that the proposed automated tricks implement a seamless, fully realized and Qubes-integrated runtime environment would be risible. Its one thing to say we're "treating a guest Linux like a runtime framework and guessing about idle status based on X criteria" and quite another to say "it is The Qubes Runtime Environment and it handles idle states".

Having this touted as fully automatic "idle" handling is just a recipe for woe.

As for making guests "as seamless as possible", I guess that can be intepreted in a number of ways. We already have the "seamless" windowing environment, where "seamless" is an industry term applied to VMs that display app windows independantly. It does not mean a whole lot more than that, as you're implying. This is an OS based on isolation and its expression in the user interface.

tasket · Dec 22, 2016

A non-tech user (e.g. journalist) will not want to config anything, (s)he will want it to be working. I don't believe such user will run background tasks without any GUI, except those that are related to Qubes itself (e.g. file copy). Note that even IM applications show at least some systray icon. So, Qubes could handle all those cases automatically well. I believe that Qubes is also targeting those users.

@v6ak : Um, non-tech users have a way of finding functions in their GUI programs that do realize corner cases... such as processes that collect info or render projects in the background.

Suggesting to these--or any other--users that the proposed automated tricks implement a seamless, fully realized and Qubes-integrated runtime environment would be risible. Its one thing to say we're "treating a guest Linux like a runtime framework and guessing about idle status based on X criteria" and quite another to say "it is The Qubes Runtime Environment and it handles idle states".

Having this touted as fully automatic "idle" handling is just a recipe for woe.

As for making guests "as seamless as possible", I guess that can be intepreted in a number of ways. We already have the "seamless" windowing environment, where "seamless" is an industry term applied to VMs that display app windows independantly. It does not mean a whole lot more than that, as you're implying. This is an OS based on isolation and its expression in the user interface.

Whats funny about this (both funny-strange and funny-haha bc I had to chuckle :) ) is that guest systems already have the means to timeout on idle, and automatically suspend or shutdown. I have not seen ONE OS that uses open windows as criteria, ever.

They also have methods to prevent entry into standby or shutdown. Some call it "presentation mode" though it could be used for anything. In Linux there's also systemd-inhibit.

If it has to be "open windows" in this case, will it respect the those rules?

tasket · Dec 22, 2016

Whats funny about this (both funny-strange and funny-haha bc I had to chuckle :) ) is that guest systems already have the means to timeout on idle, and automatically suspend or shutdown. I have not seen ONE OS that uses open windows as criteria, ever.

They also have methods to prevent entry into standby or shutdown. Some call it "presentation mode" though it could be used for anything. In Linux there's also systemd-inhibit.

If it has to be "open windows" in this case, will it respect the those rules?

"I have not seen ONE OS that uses open windows as criteria, ever." It stands to reason that introducing a (brave) new criteria like this should be in a form that's explicit.

Seamlessness will come later when Qubes is in the business of actually defining runtime environments. When you see AppVMs 1/10th the size, boot and halt in 2 seconds, and the appVM race conditions are moot, that's when the prerequisites for seamlessness will be filled.

tasket · Dec 22, 2016

"I have not seen ONE OS that uses open windows as criteria, ever." It stands to reason that introducing a (brave) new criteria like this should be in a form that's explicit.

Seamlessness will come later when Qubes is in the business of actually defining runtime environments. When you see AppVMs 1/10th the size, boot and halt in 2 seconds, and the appVM race conditions are moot, that's when the prerequisites for seamlessness will be filled.

Using systemd-inhibit (or equivalent) is a good idea! IMO much better than `touch /rw/never-idle`. Of course it does not obsolete mechanism to turn off the whole service. As for idle detection on bare-metal system, it isn't really the same case. On bare-metal system see how user interact with the whole system. In Qubes VM, Linux is mere API provider (aka runtime environment) seeing only how user interact with selected applications. For example VM do not see if the user do anything on other desktops, or even in on the same desktop but in a window belonging to a different VM. And we're not talking about the case of suspending the whole system (when user is away), but a single VM, when user do not use it (but may use a different one). So applying the same criteria here does not make sense. @tasket Anyway if this service does not fit your workflow, you're free to disable it. But I think it should fit most users (when correctly configured), and everyone in this discussion besides you agree with this.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

marmarek · Dec 22, 2016

Using systemd-inhibit (or equivalent) is a good idea! IMO much better than `touch /rw/never-idle`. Of course it does not obsolete mechanism to turn off the whole service. As for idle detection on bare-metal system, it isn't really the same case. On bare-metal system see how user interact with the whole system. In Qubes VM, Linux is mere API provider (aka runtime environment) seeing only how user interact with selected applications. For example VM do not see if the user do anything on other desktops, or even in on the same desktop but in a window belonging to a different VM. And we're not talking about the case of suspending the whole system (when user is away), but a single VM, when user do not use it (but may use a different one). So applying the same criteria here does not make sense. @tasket Anyway if this service does not fit your workflow, you're free to disable it. But I think it should fit most users (when correctly configured), and everyone in this discussion besides you agree with this.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

@marmarek : Something you should keep in mind while implementing this is that runtime environments typically have intimate access to the bare-metal systems in which they run (and vice-versa). "It isn't really the same case" as you say, not because of implementation details but because of a fundamental difference involving isolation.

tasket · Dec 22, 2016

@marmarek : Something you should keep in mind while implementing this is that runtime environments typically have intimate access to the bare-metal systems in which they run (and vice-versa). "It isn't really the same case" as you say, not because of implementation details but because of a fundamental difference involving isolation.

Cross linking: https://groups.google.com/d/msg/qubes-devel/EzIYnD-AMr4/EsHWNPyfDAAJ

jpouellet · Feb 3, 2017

Cross linking: https://groups.google.com/d/msg/qubes-devel/EzIYnD-AMr4/EsHWNPyfDAAJ

Is there a reason we are not considering hibernation (#2273) rather than shutdown of inactive VMs?

mfc · Mar 12, 2017

Is there a reason we are not considering hibernation (#2273) rather than shutdown of inactive VMs?

Yes, shutdown is much easier to implement. For suspend/restore you need not only to restore VM internal state (memory etc - handled by Xen tools), but also all related VM connections - networking, GUI, qrexec services running when VM was hibernated etc.
Also, VM suspend support in Xen/Linux historically was quite buggy - this is for example why Disposable VMs have only 1 vCPU assigned, otherwise it crashed frequently. Probably situation have improved since previous tests, but still I suspect it will be less stable.

marmarek · Mar 12, 2017

Yes, shutdown is much easier to implement. For suspend/restore you need not only to restore VM internal state (memory etc - handled by Xen tools), but also all related VM connections - networking, GUI, qrexec services running when VM was hibernated etc.
Also, VM suspend support in Xen/Linux historically was quite buggy - this is for example why Disposable VMs have only 1 vCPU assigned, otherwise it crashed frequently. Probably situation have improved since previous tests, but still I suspect it will be less stable.

Shutdown:

is much better for making VM up-to-date: When you update a VM, you have to restart it. If a VM hibernates, it would have to be restored to the old state. Consider a following scenario: You start a banking VM, then you close the browser. It gets hibernated. Then you update the TemplateVM. Then you might even reboot your computer. And even in this case, the banking VM will still use the outdated template. Not nice.
is probably less resource-intensive (at least for I/O) than hibernate
does not break potential anti-forensic nature like hibernate would do
the reverse process (i.e., VM start) might take slightly more time than with hibernation (i.e., VM restore)

I know there can be some arguments for preserving the state. But if you need it, you probably use Qubes wrong. And keeping outdated VMs (i.e., making it worse than today) is a great argument against use of hibernation here, I believe.

v6ak · Mar 12, 2017

Shutdown:

is much better for making VM up-to-date: When you update a VM, you have to restart it. If a VM hibernates, it would have to be restored to the old state. Consider a following scenario: You start a banking VM, then you close the browser. It gets hibernated. Then you update the TemplateVM. Then you might even reboot your computer. And even in this case, the banking VM will still use the outdated template. Not nice.
is probably less resource-intensive (at least for I/O) than hibernate
does not break potential anti-forensic nature like hibernate would do
the reverse process (i.e., VM start) might take slightly more time than with hibernation (i.e., VM restore)

I know there can be some arguments for preserving the state. But if you need it, you probably use Qubes wrong. And keeping outdated VMs (i.e., making it worse than today) is a great argument against use of hibernation here, I believe.

On Mar 12, 2017 8:39 PM, "Vít Šesták" <notifications@github.com> wrote: Shutdown: - is much better for making VM up-to-date: When you update a VM, you have to restart it. If a VM hibernates, it would have to be restored to the old state. Consider a following scenario: You start a banking VM, then you close the browser. It gets hibernated. Then you update the TemplateVM. Then you might even reboot your computer. And even in this case, the banking VM will still use the outdated template. Not nice. I'd like to have limited hibernate anyway. I.e. if hibernate will destroy vm with missing template or require reboot of app vm once the template has changed - it's okay. - is probably less resource-intensive (at least for I/O) than hibernate When I'm moving to long trip I've to either shutdown or suspend to RAM . If I susppend to RAM - I may loose all VM states once battery is over. What I really never care from user point of view is how much i/o it takes. - does not break potential anti-forensic nature like hibernate would do All forensics outside of crypto container is not something you should care about, isn't it? It's good to provide a warning though. - the reverse process (i.e., VM start) might take slightly more time than with hibernation (i.e., VM restore) I know there can be some arguments for preserving the state. But if you need it, you probably use Qubes wrong. What I really need is usability. And keeping outdated VMs (i.e., making it worse than today) is a great argument against use of hibernation here, I believe. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#832 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALHcA3dFpogAKiT3RiosmJ2WOXUuDnu2ks5rlC3UgaJpZM4DrUd6> .

grey-olli · Mar 24, 2017

On Mar 12, 2017 8:39 PM, "Vít Šesták" <notifications@github.com> wrote: Shutdown: - is much better for making VM up-to-date: When you update a VM, you have to restart it. If a VM hibernates, it would have to be restored to the old state. Consider a following scenario: You start a banking VM, then you close the browser. It gets hibernated. Then you update the TemplateVM. Then you might even reboot your computer. And even in this case, the banking VM will still use the outdated template. Not nice. I'd like to have limited hibernate anyway. I.e. if hibernate will destroy vm with missing template or require reboot of app vm once the template has changed - it's okay. - is probably less resource-intensive (at least for I/O) than hibernate When I'm moving to long trip I've to either shutdown or suspend to RAM . If I susppend to RAM - I may loose all VM states once battery is over. What I really never care from user point of view is how much i/o it takes. - does not break potential anti-forensic nature like hibernate would do All forensics outside of crypto container is not something you should care about, isn't it? It's good to provide a warning though. - the reverse process (i.e., VM start) might take slightly more time than with hibernation (i.e., VM restore) I know there can be some arguments for preserving the state. But if you need it, you probably use Qubes wrong. What I really need is usability. And keeping outdated VMs (i.e., making it worse than today) is a great argument against use of hibernation here, I believe. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#832 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALHcA3dFpogAKiT3RiosmJ2WOXUuDnu2ks5rlC3UgaJpZM4DrUd6> .

Well, I am not against having hibernation in Qubes. I am saying: 1. It is hard and has its sharp edges. 2. It is not suitable for automatic cleanup of unused VMs. Some of my arguments against are valid only against automatic hibernation of unused VMs.

I'd like to have limited hibernate anyway. I.e. if hibernate will destroy vm with missing template or require reboot of app vm once the template has changed - it's okay.

VM with missing template – maybe this should not happen in the first place and this is hardly something I've mentioned. But consider VM template change. Currently, Qubes uses volatile.img for saving template modifications (and swap) and AFAIK root.cow.img for tracking changes of template's root.img. When implementing hibernate for template-based VMs, Qubes would have to keep not only volatile.img (which should be easy), but also all relevant versions of root.cow.img. And what's worse: Qubes would have to update all of them when template is being modified. That's bad for two reasons: * It requires nontrivial implementation effort, I think. * Some unused hibernated template-based VM can slow down template updates. Maybe this could be solved in various ways, but it further increases complexity of the task. Of course, we can put some limitation on hibernation in order to make things easier. But I am not sure who would be satisfied with the result: a. When VM template has a hibernated template-based VM, don't allow to start it. This prevents those issues, but it is a huge counter-intuitive restriction. b. When template VM is started, remove all saved states of related template-based VMs. This is also a huge counter-intuitive limitation. c. Don't hibernate per-VM. Allow just hibernating and restoring all the VMs. Maybe this is closest to your use case and most intuitive, although most restricted solution. But this is becoming totally offtopic when we are discussing what to do with VMs that aren't being used.

What I really never care from user point of view is how much i/o it takes.

It is not an issue for hibernation on demand, but it is for hibernating VMs automatically. Maybe end user will not care about IO load, but she will care about some sudden hiccups caused by some background process.

- does not break potential anti-forensic nature like hibernate would do All forensics outside of crypto container is not something you should care about, isn't it? It's good to provide a warning though.

Today, Qubes can be easily tuned for storing volatile.img on a separate partition encrypted by a random key stored only in RAM. Hibernation breaks this.

v6ak · Mar 24, 2017

Well, I am not against having hibernation in Qubes. I am saying: 1. It is hard and has its sharp edges. 2. It is not suitable for automatic cleanup of unused VMs. Some of my arguments against are valid only against automatic hibernation of unused VMs.

I'd like to have limited hibernate anyway. I.e. if hibernate will destroy vm with missing template or require reboot of app vm once the template has changed - it's okay.

VM with missing template – maybe this should not happen in the first place and this is hardly something I've mentioned. But consider VM template change. Currently, Qubes uses volatile.img for saving template modifications (and swap) and AFAIK root.cow.img for tracking changes of template's root.img. When implementing hibernate for template-based VMs, Qubes would have to keep not only volatile.img (which should be easy), but also all relevant versions of root.cow.img. And what's worse: Qubes would have to update all of them when template is being modified. That's bad for two reasons: * It requires nontrivial implementation effort, I think. * Some unused hibernated template-based VM can slow down template updates. Maybe this could be solved in various ways, but it further increases complexity of the task. Of course, we can put some limitation on hibernation in order to make things easier. But I am not sure who would be satisfied with the result: a. When VM template has a hibernated template-based VM, don't allow to start it. This prevents those issues, but it is a huge counter-intuitive restriction. b. When template VM is started, remove all saved states of related template-based VMs. This is also a huge counter-intuitive limitation. c. Don't hibernate per-VM. Allow just hibernating and restoring all the VMs. Maybe this is closest to your use case and most intuitive, although most restricted solution. But this is becoming totally offtopic when we are discussing what to do with VMs that aren't being used.

What I really never care from user point of view is how much i/o it takes.

It is not an issue for hibernation on demand, but it is for hibernating VMs automatically. Maybe end user will not care about IO load, but she will care about some sudden hiccups caused by some background process.

- does not break potential anti-forensic nature like hibernate would do All forensics outside of crypto container is not something you should care about, isn't it? It's good to provide a warning though.

Today, Qubes can be easily tuned for storing volatile.img on a separate partition encrypted by a random key stored only in RAM. Hibernation breaks this.

marmarek added this to the Release 3 milestone Mar 8, 2015

marmarek added enhancement C: core P: major labels Mar 8, 2015

marmarek referenced this issue Mar 8, 2015
Closed
Convenient VM shutdown features #912

marmarek modified the milestones: Release 3.1, Release 3.0 May 13, 2015

marmarek changed the title from Pause/suspend inactive VMs to Shutdown/suspend inactive VMs Nov 23, 2015

marmarek modified the milestones: Release 3.2, Release 3.1 Feb 8, 2016

marmarek referenced this issue Jul 4, 2016
Open
Qubes Manager Decomposition for Qubes 4.0 #2132
7 of 7 tasks complete

marmarek modified the milestones: Release 3.2, Release 4.0 Aug 5, 2016

marmarek modified the milestones: Release 4.0, Release 3.2 Aug 5, 2016

marmarek referenced this issue Aug 30, 2016
Open
Consider supporting VM hibernation (xl save/restore) #2273

jpouellet referenced this issue Jul 24, 2017
Closed
Freezing a running VM #2936

andrewdavidwong modified the milestones: Release 4.0, Release 4.1 Mar 31, 2018

QubesOS/qubes-issues

Join GitHub today

Shutdown/suspend inactive VMs #832

Comments

marmarek commented Mar 8, 2015

marmarek added this to the Release 3 milestone Mar 8, 2015

marmarek added enhancement C: core P: major labels Mar 8, 2015

This comment has been minimized.

marmarek commented Mar 8, 2015

marmarek referenced this issue Mar 8, 2015

This comment has been minimized.

v6ak commented May 7, 2015

This comment has been minimized.

marmarek commented May 11, 2015

marmarek modified the milestones: Release 3.1, Release 3.0 May 13, 2015

This comment has been minimized.

v6ak commented May 15, 2015

This comment has been minimized.

v6ak commented May 15, 2015

This comment has been minimized.

v6ak commented May 25, 2015

This comment has been minimized.

marmarek commented May 25, 2015

This comment has been minimized.

marmarek commented May 25, 2015

This comment has been minimized.

v6ak commented May 25, 2015

This comment has been minimized.

marmarek commented May 25, 2015

This comment has been minimized.

v6ak commented May 25, 2015

This comment has been minimized.

adrelanos commented Nov 4, 2015

This comment has been minimized.

bnvk commented Nov 21, 2015

This comment has been minimized.

adrelanos commented Nov 21, 2015

This comment has been minimized.

marmarek commented Nov 21, 2015

This comment has been minimized.

adrelanos commented Nov 22, 2015

This comment has been minimized.

v6ak commented Nov 23, 2015

marmarek changed the title from Pause/suspend inactive VMs to Shutdown/suspend inactive VMs Nov 23, 2015

This comment has been minimized.

marmarek commented Nov 23, 2015

This comment has been minimized.

v6ak commented Nov 23, 2015

This comment has been minimized.

marmarek commented Nov 23, 2015

This comment has been minimized.

v6ak commented Nov 28, 2015

This comment has been minimized.

marmarek commented Nov 28, 2015

This comment has been minimized.

mfc commented Dec 3, 2015

marmarek modified the milestones: Release 3.2, Release 3.1 Feb 8, 2016

marmarek referenced this issue Jul 4, 2016

This comment has been minimized.

tasket commented Jul 4, 2016

This comment has been minimized.

marmarek commented Jul 4, 2016

This comment has been minimized.

tasket commented Jul 5, 2016 • edited Edited 1 time tasket edited Jul 5, 2016 (most recent)

This comment has been minimized.

marmarek commented Jul 5, 2016

marmarek modified the milestones: Release 3.2, Release 4.0 Aug 5, 2016

marmarek modified the milestones: Release 4.0, Release 3.2 Aug 5, 2016

marmarek referenced this issue Aug 30, 2016

This comment has been minimized.

marmarek commented Dec 21, 2016

This comment has been minimized.

tasket commented Dec 21, 2016

This comment has been minimized.

jpouellet commented Dec 21, 2016 • edited Edited 1 time jpouellet edited Dec 21, 2016 (most recent)

This comment has been minimized.

tasket commented Dec 21, 2016

This comment has been minimized.

jpouellet commented Dec 21, 2016

This comment has been minimized.

tasket commented Jul 5, 2016 •

edited

Edited 1 time

tasket edited Jul 5, 2016 (most recent)

jpouellet commented Dec 21, 2016 •

edited

Edited 1 time

jpouellet edited Dec 21, 2016 (most recent)