Improve UX regarding VM pausing

[andrewdavidwong]

The problem you're addressing (if any)

Most users don't know what pausing a VM does or when they should do it.

Describe the solution you'd like

Some better way for Qubes OS to make VM pausing intuitive for users, or just improve the UX regarding VM pausing in general, however you deem best.

Where is the value to a user, and who might that user be?

Users won't use the pause functionality for the wrong reasons or in the wrong way. Users won't see the pause button and wonder fearfully what it does.

Describe alternatives you've considered

Document information about pausing VMs. This would also be good, but of course not everyone will read the documentation.

Additional context

See the discussion on #5988.

Relevant documentation you've consulted

We currently don't mention pausing much in the documentation. Understanding and Preventing Data Leaks mentions it in passing.

Related, non-duplicate issues

#5988, #5987, #5967, #5305, #4700, #4101

[3hhh]

Yes, and don't forget to mention that unpause is not expected to work - especially after a while.

[brendanhoar]

If resume isn’t really supposed to work, why is it in the menu?

[marmarek]

On Mon, Aug 10, 2020 at 10:52:58AM -0700, Brendan Hoar wrote: If resume isn’t really supposed to work, why is it in the menu?

It does work if you do it relatively shortly after pause - up to something like few tens minutes after.

[brendanhoar]

“it works unless you take a phone call
or lunch break” is not really a working feature. If it must be presented to UI users, I suggest adding an “Are you sure you wish to pause this VM? The unpause feature often fails.” OK/cancel dialog, at a minimum, to the UI invocations.

Or, make it more reliable.

B

[GWeck]

It would also be helpful if the difference between pause and suspend were documnented a bit more. Also, on the shutdown screen both operations are offered, but it is not clear what is the difference.

[marmarta]

I have one big UI problems here - providing description in the domains-widget and in Qube Manager is difficult (almost nobody reads tooltips :( ), and reacting to every pause with a "are you sure" message box may be annoying (and showing it just once will mean roughly 80% of people will not read it). I could perhaps add a warning with "don't show this warning for X days/this VM/until next reboot"...

Maybe we should rename it to something like Emergency Pause?

@brendanhoar as far as I can tell, this is a problem with Linux kernel, hard to fix on our side.

@GWeck this I think is part of the bigger "Linux tools have unclear UI" problem - the shutdown widget is just basic XFCE, so there's no very simple way of modifying it without having to maintain our separate fork :( I would love to have a more customized and usable window manager one day...

[3hhh]

+1 from me for "emergency pause" unless it's fixed.

[andrewdavidwong]

If unpausing is only expected to work for up to ~30 mins, then how about, when you pause a VM, a little widget pops up that says, for example:

The work qube can be unpaused for the next:

21m 32s

[Unpause]

(Or some better version of this.)

[brendanhoar]

If unpausing is only expected to work for up to ~30 mins, then how about, when you pause a VM, a little widget pops up that says, for example:

The work qube can be unpaused for the next:
21m 32s
[Unpause]

Unfortunately the cause of the failed unpause isn’t that deterministic.

B

[andrewdavidwong]

Unfortunately the cause of the failed unpause isn’t that deterministic.

I'm not sure what you mean. I don't see how my idea depends on the cause being deterministic, unless that entails that there is no safe minimum time at which to set the threshold.

[marmarta]

Yeah, I don't think there is a useful safe minimum time that can be determined here. It's "something, probably around a couple dozen minutes, 5 minutes is definitely safe, but is 20 fine always? Is 30? Who knows."

…

On Sat, Aug 15, 2020, 08:45 Andrew David Wong ***@***.***> wrote: Unfortunately the cause of the failed unpause isn’t that deterministic. I'm not sure what you mean. I don't see how my idea depends on the cause being deterministic, unless that entails that there is *no* safe minimum time at which to set the threshold. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5993 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXIEOUUA2QK4OUEWJ6NGX3SAYVHPANCNFSM4PZZXC2A> .

[ninavizz]

Guys—is there a reason it's not just called "Quit VM" or "Shut Down VM?" I feel that much of the problem, is splitting hairs in an effort to be as technically accurate as possible... and muddling usability, in the process.

Including descriptions in a dropdown menu doesn't feel like an acceptable solution for this. What the function is called, needs to speak clearly enough for itself.

Yes, reading through the above, I'm also gathering I don't understand the functionality, myself... which, again, then, speaks to needing to make it more self-evident in the UI. We can't count on ppl to read documentation; although a compromise, would be including contextual help within the menu itself (and I've done a mockup of that, somewhere).

[marmarta]

It's a different option, not shut down - pausing keeps the state and can be unpaused (although as you can see above not indefinitely), shutting down performs system halt inside the VM.

…

On Fri, Sep 4, 2020, 21:44 Nina Eleanor Alter ***@***.***> wrote: Guys—is there a reason it's not just called "Quit VM" or "Shut Down VM?" I feel that much of the problem, is splitting hairs in an effort to be as technically accurate as possible... and muddling usability, in the process. Including descriptions in a dropdown menu doesn't feel like an acceptable solution for this. What the function is called, needs to speak clearly enough for itself. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5993 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXIEOUXGIKXNO63SDC7YLTSEE7TJANCNFSM4PZZXC2A> .

[ninavizz]

On Mon, Aug 10, 2020 at 10:52:58AM -0700, Brendan Hoar wrote: If resume isn’t really supposed to work, why is it in the menu?
It does work if you do it relatively shortly after pause - up to something like few tens minutes after.

Can the "un-pause" option in the dropdown have a live countdown-timer on it that then disables this option entirely, after 10min? To me, that sounds like the most obvious solution in the UI itself.

More options to learn about stuff, contextually, throughout all the UIs seems like a broader but solid need, longer-term. Mostly because so many things in Qubes speak to non-existent mental models for almost all users.

[3hhh]

I think I found a one-line removal fix for the root cause, i.e. this one can be likely reverted to the original wording.

Details in #5988

[ninavizz]

If it the issue of paused VMs effectively freezing or crashing in-stasis at some point could be fixed so that doesn't happen, yay! If not: would it be possible to change the "status" of a VM from Paused to Frozen or Crashed or something speaking to a need to kill it?

[deeplow]

Well, pausing is something you do to a VM. Not something that happens on its own (like freeze or crash).

I would suggests that this feature is either supported or removed from the GUI entirely until it works reliably. It would also reduce the information load in some Qubes Domains widget. And one can always qvm-pause (and some Warning could be easily added there).

---

On another note, it is hard to tell paused VMs apart. I would suggest that when a VM is paused it should have a grey-ish tone to it. Kind of like the "blue" in alt-tab:

The XFCE's alt-tab code I believe is this. Possibly also a Resume button at the center.

[ninavizz]

No linked PR and 4.1 is nearing release. I really like @deeplow's idea with the tinting of a window with a Resume button at the center, but also feel the functionality should to function reliably; and yet the effort to make that possible, feels so low on the broader order of priorities.

Thoughts?

[3hhh]

Fyi:

I use the following as salt fix:

# -*- coding: utf-8 -*-
# vim: set syntax=yaml ts=2 sw=2 sts=2 et :
#
# Fix https://github.com/QubesOS/qubes-issues/issues/5988 - make unpausing a VM after a longer time work.
#

#remove the systemd-logind watchdog as it restarts systemd-logind after an unpause, which in turn causes X to shut itself down, which then causes qubes-gui-daemon to fail & dispVMs to shut down
remove-systemd-logind-watchdog:
  file.replace:
    - name: /usr/lib/systemd/system/systemd-logind.service
    - pattern: '^WatchdogSec=.*$'
    - repl: ''

[deeplow]

but also feel the functionality should to function reliably;

Yup. This is a requirement. But if @3hhh's thing solves it then it should be implemented. Regardless, on the current 4.1 testing release it is labled as emergency pause. With that priority I don't think users are likely to click there. And if they do, they may remember they paused it.

So I don't think this should be a priority.