Get rid of the "Cannot start qrexec for domain XYZ, do you want to wait or not" message

[marmarek]

Reported by joanna on 2 Feb 2014 10:53 UTC
Nobody likes "modal" dialog boxes that ask strange questions nobody knows why!

Just display a notification message and automatically kill the VM and perhaps automatically attempt to start it again.

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

[marmarek]

Comment by marmarek on 2 Feb 2014 11:47 UTC
I don't think automatic restart is a good idea.
One use case when this dialog make sense: Windows HVM start. Sometimes it takes a long time for Windows to startup (for example when installing some updates, or running checkdisk) - the VM shouldn't be killed in such case, perhaps the user should increase qrexec_timeout setting (but still - killing the VM during such such startup can have bad effects).

Perhaps we should distinguish here between PV and HVM? For PV unconditionally kill the VM failing its startup, but for HVM just keep the message?

[marmarek]

Comment by marmarek on 2 Feb 2014 11:47 UTC
I don't think automatic restart is a good idea.
One use case when this dialog make sense: Windows HVM start. Sometimes it takes a long time for Windows to startup (for example when installing some updates, or running checkdisk) - the VM shouldn't be killed in such case, perhaps the user should increase qrexec_timeout setting (but still - killing the VM during such such startup can have bad effects).

Perhaps we should distinguish here between PV and HVM? For PV unconditionally kill the VM failing its startup, but for HVM just keep the message?

[marmarek]

Comment by joanna on 2 Feb 2014 12:08 UTC
Keeping the message popping up is against UI ergonomy -- there is nothing here that a user should be able to decide better than software, so asking the user about it makes no sense and is only annoying.

Let's think more about this: does the user has any more clues to answer that question meaningfully than our software stack? If yes, then why can't we incorporate this logic into our software stack? If no, then asking user makes no sense anyway.

[marmarek]

Comment by joanna on 2 Feb 2014 12:08 UTC
Keeping the message popping up is against UI ergonomy -- there is nothing here that a user should be able to decide better than software, so asking the user about it makes no sense and is only annoying.

Let's think more about this: does the user has any more clues to answer that question meaningfully than our software stack? If yes, then why can't we incorporate this logic into our software stack? If no, then asking user makes no sense anyway.

[marmarek]

Comment by marmarek on 2 Feb 2014 12:11 UTC
Yes the user have more clues: sees windows installing its updates (or sth like this). I don't see our tool doing OCR of windows screen...

[marmarek]

Comment by marmarek on 2 Feb 2014 12:11 UTC
Yes the user have more clues: sees windows installing its updates (or sth like this). I don't see our tool doing OCR of windows screen...

[marmarek]

Comment by joanna on 2 Feb 2014 12:15 UTC
So how about, instead of panicking and displaying this dialog to the user, just keep trying to connect qrexec/guid to the VM? I.e. the only signal that they didn't connect would be the yellow dot in the manager. Plus an error message appearing whenever user tries to qrexec to the VM (e.g. qvm-run something there). The error message should, of course, appear in the notification tray, like other error message, not via kdialog!

[marmarek]

Comment by joanna on 2 Feb 2014 12:15 UTC
So how about, instead of panicking and displaying this dialog to the user, just keep trying to connect qrexec/guid to the VM? I.e. the only signal that they didn't connect would be the yellow dot in the manager. Plus an error message appearing whenever user tries to qrexec to the VM (e.g. qvm-run something there). The error message should, of course, appear in the notification tray, like other error message, not via kdialog!

[marmarek]

Comment by marmarek on 2 Feb 2014 12:20 UTC
Ok for me. But still one issue to solve: what about qvm-run -a VM some-program?

[marmarek]

Comment by marmarek on 2 Feb 2014 12:20 UTC
Ok for me. But still one issue to solve: what about qvm-run -a VM some-program?

[marmarek]

Comment by joanna on 2 Feb 2014 12:21 UTC
Failed qvm-run -a --> tray notification after timeout.

[marmarek]

Comment by joanna on 2 Feb 2014 12:21 UTC
Failed qvm-run -a --> tray notification after timeout.

[marmarek]

Modified by marmarek on 5 Feb 2014 02:33 UTC

[marmarek]

Modified by marmarek on 5 Feb 2014 02:33 UTC

[marmarek]

Comment by marmarek on 8 Feb 2014 11:28 UTC
http://git.qubes-os.org/?p=marmarek/core-admin-linux.git;a=commit;h=f77e2d656d3b554ad5309736fc427b55e7d81105
http://git.qubes-os.org/?p=marmarek/core-admin.git;a=commit;h=86d3e2f4dd2a9ee1f59e12d4bed8ba455db620dd

[marmarek]

Comment by marmarek on 8 Feb 2014 11:28 UTC
http://git.qubes-os.org/?p=marmarek/core-admin-linux.git;a=commit;h=f77e2d656d3b554ad5309736fc427b55e7d81105
http://git.qubes-os.org/?p=marmarek/core-admin.git;a=commit;h=86d3e2f4dd2a9ee1f59e12d4bed8ba455db620dd

[mdik]

Right now I'm running into timeouts when doing
qvm-create-default-dvm whonix-ws
and I would really appreciate either a longer timeout, or the option to wait a bit longer :-}

[mdik]

Right now I'm running into timeouts when doing
qvm-create-default-dvm whonix-ws
and I would really appreciate either a longer timeout, or the option to wait a bit longer :-}