Display an icon indicating the VM is in some transient state

[marmarek]

Reported by joanna on 14 Apr 2012 12:30 UTC
Currently we either display a Green dot, indicating the VM is running, or not, implicitly indicting the VM is stopped. However, the VM might be in other states between Running and Halted, such as e.g. "Halting". It is important to indicate this to the user (e.g. by displaying a yellow icon), as otherwise the user things the VM is shutdown and might be trying to e.g. start it again, which however will fail, as the VM is still in some other state, not ready for another start. This is confusing.

Perhaps this could be done by adding an is_in_transient_state() method to QubesVm class, and for all domains where this is true, to display a yellow icon.

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

[marmarek]

Comment by marmarek on 18 Apr 2012 09:15 UTC
vm.get_power_state() already returns states like "Halting", "Dying" (or even "Crashed") in appropriate situations.
vm.is_running is implemented as 'get_power_state() == "Running"' - perhaps it should include also "Halting"?

[marmarek]

Comment by marmarek on 18 Apr 2012 09:15 UTC
vm.get_power_state() already returns states like "Halting", "Dying" (or even "Crashed") in appropriate situations.
vm.is_running is implemented as 'get_power_state() == "Running"' - perhaps it should include also "Halting"?

[marmarek]

Comment by joanna on 18 Apr 2012 21:05 UTC
No, because we want to display either a nice green icon, indicating that the VM is running and is fully usable vs. when the VM is either starting up or shutting down, and is not really "available" in a way the green icon would suggest. So the cycle, from the user point of view should look like this:

1. VM is not running (no icon displayed, VM not included in the active list)
2. VM is starting up (yellow icon is displayed, VM is included in the active list)
3. VM started fine, is available or usable (green icon)
4. VM is shutting down (yellow icon, VM still on the active list)
5. VM halted, not included in xl list (no icon, not on active list) -- this is the same as #1

One things to consider:

Perhaps the green icon (#3 above) should appear only after qrexec connected fine, and before that happens we should still be showing a yellow icon, even though the VM is in state Running already. I think we should go this way, unless it was somehow difficult to implement.

[marmarek]

Comment by joanna on 18 Apr 2012 21:05 UTC
No, because we want to display either a nice green icon, indicating that the VM is running and is fully usable vs. when the VM is either starting up or shutting down, and is not really "available" in a way the green icon would suggest. So the cycle, from the user point of view should look like this:

1. VM is not running (no icon displayed, VM not included in the active list)
2. VM is starting up (yellow icon is displayed, VM is included in the active list)
3. VM started fine, is available or usable (green icon)
4. VM is shutting down (yellow icon, VM still on the active list)
5. VM halted, not included in xl list (no icon, not on active list) -- this is the same as #1

One things to consider:

Perhaps the green icon (#3 above) should appear only after qrexec connected fine, and before that happens we should still be showing a yellow icon, even though the VM is in state Running already. I think we should go this way, unless it was somehow difficult to implement.

[marmarek]

Comment by marmarek on 18 Apr 2012 22:10 UTC
Will try to implement somehow "Starting" state (detection of qrexec and/or guid state), but this will not work in every case (some VMs can have not qrexec or guid, but still be usable).
Also this is difficult to differentiate lack of guid reason - starting or halting...
Anyway Aga - you can assume that there is also "Starting" state.

[marmarek]

Comment by marmarek on 18 Apr 2012 22:10 UTC
Will try to implement somehow "Starting" state (detection of qrexec and/or guid state), but this will not work in every case (some VMs can have not qrexec or guid, but still be usable).
Also this is difficult to differentiate lack of guid reason - starting or halting...
Anyway Aga - you can assume that there is also "Starting" state.

[marmarek]

Comment by marmarek on 18 Apr 2012 23:16 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=3d316ca2f96f156f4582cf8854d08294afb66c89

[marmarek]

Comment by marmarek on 18 Apr 2012 23:16 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/core.git;a=commit;h=3d316ca2f96f156f4582cf8854d08294afb66c89

[marmarek]

Comment by aga on 19 Apr 2012 13:05 UTC
I was also thinking about is_starting() state in manager. There's a well-separated piece of code responsible for starting a vm and the manager knows exactly when the starting begins and when it ends (and shows tray baloons connected with that).

But the super-weak point of this is that it would only work with starting vms from manager, not with qvm-start.

However - if the solution offered by Marek doesn't always work - it may be a way of making it slightly better...

[marmarek]

Comment by aga on 19 Apr 2012 13:05 UTC
I was also thinking about is_starting() state in manager. There's a well-separated piece of code responsible for starting a vm and the manager knows exactly when the starting begins and when it ends (and shows tray baloons connected with that).

But the super-weak point of this is that it would only work with starting vms from manager, not with qvm-start.

However - if the solution offered by Marek doesn't always work - it may be a way of making it slightly better...

[marmarek]

Comment by aga on 20 Apr 2012 16:40 UTC
http://git.qubes-os.org/?p=aga/qubes-manager.git;a=commit;h=a6f9619d60fa1194b37733e04e69a4353e08581d

[marmarek]

Comment by aga on 20 Apr 2012 16:40 UTC
http://git.qubes-os.org/?p=aga/qubes-manager.git;a=commit;h=a6f9619d60fa1194b37733e04e69a4353e08581d