GNOME Bugzilla – Bug 694931
Automatically save background VMs
Last modified: 2016-03-31 13:22:00 UTC
This is a clone of https://bugzilla.gnome.org/show_bug.cgi?id=688980#c16 so that we can close that bug while discussing this idea and track its implementation (if we go with it) here: "I think exposing the distinction between pausing and saving would be a failure from the UI point of view. When we discussed this with Zeeshan on IRC I made a parallel to the suspend to RAM vs hibernate to disk etudes we had for the OS*. One of the questions was whether to have some UI for when we are flushing to disk on quit when that action can potentially take a while (10seconds +). I don't even think we should be explicitly asking the user to pause a box. Saving state can be completely transparent. Why not default to only keep one running VM per Boxes window. Transparently save in the background everything that's not showing up. Allow to explicitly keep a box running in the background of course in the properties, but the default would be to suspend. There may be some more exceptions (running installation comes to mind). Remembering Evolution, I don't think exposing the saving on quit is a wise choice. Do we have some system policies that would kill boxes when shutting down for example? * http://fedoraproject.org/wiki/Desktop/Whiteboards/HybridSuspend" -- Jakub Steiner
Whether we want to expose 'pause' in UI anymore, we might want to still consider automatically putting machines to paused state independently. We might want to limit this to hosts with limited resources.
I'd pledge for the following: - If the user opens a VM it gets started/unpaused. - If the user closes a VM it gets paused automatically if it is not an active express installation. - There is no pause button or any other exposure of the pausing/saving concept for VMs in the UI. - If a VM is express installing it gets a "Pause installation"/"Resume installation" button in the selection menu and the context menu (which is planned IIRC) IMO this is the most intuitive thing we can do (although I'm not as sure about the special case with the express installation). Either I use the VM or not, no need for pausing or similar concepts. Since we have multiple windows the user can still run multiple VMs at the same time.
I think I can agree to plan in comment#2 but: 1. We should have a timeout before we automatically pause VMs. 2. Not sure about providing a special pause for express installation. Maybe its a good idea, maybe not.
(In reply to comment #3) > I think I can agree to plan in comment#2 but: > > 1. We should have a timeout before we automatically pause VMs. Why? From user perspective, if we want to make it simple IMO we need to get away from the pausing concept. The idea is that there isnt any pausing anymore but only active or not. (While active means a window is open and the VM is running, both is not true for inactive.) So there can be a timeout internally but I'd gray out the screenshot immediately if the user closes the VM window. There should be no indications "pausing..." or "saving..." or so. Just a spinner if it takes some time to reopen a vm will do IMO.
(In reply to comment #4) > (In reply to comment #3) > > I think I can agree to plan in comment#2 but: > > > > 1. We should have a timeout before we automatically pause VMs. > > Why? From user perspective, if we want to make it simple IMO we need to get > away from the pausing concept. From user's pov, there isn't much difference if pause was really as simple operation as it sounds like. It usually takes a while before VM is paused so a timeout is needed to pace ourselves for possibilites of user going back and forth quickly between overview and launching VM. Since we are handling pausing in the background automatically, it wouldn't matter (or even be visible) to user that machine is paused or not. >The idea is that there isnt any pausing anymore > but only active or not. (While active means a window is open and the VM is > running, both is not true for inactive.) So there can be a timeout internally > but I'd gray out the screenshot immediately if the user closes the VM window. > There should be no indications "pausing..." or "saving..." or so. Just a > spinner if it takes some time to reopen a vm will do IMO. Sure, assuming we still want to show the difference between paused and running VMs anymore.
Well from what I understood from jimmac and his mockups, we do want this exposed in the UI while we should also implement automatic saving of background VMs.
commit: cc0832e cc0832efadd8afcbe461cced38e2d6e526866a5a Date: Mon Nov 10 19:27:40 2014 +0000 libvirt-machine: Delay starting if being saved Connecting to a machine that is currently being saved results in an error so lets wait for saving to finish completely before we launch the machine. commit: 0461fd3 0461fd35cca2841fa836713da480edecb84b9468 Date: Tue Nov 11 20:48:28 2014 +0000 machine: Add schedule_autosave() Add a method to autosave the machine after 1 minute. commit: 5ccfbef 5ccfbef9cc63f1e84d89149319039bc94d285764 Date: Tue Nov 11 20:48:28 2014 +0000 machine: Add unschedule_autosave() Add a method to unschedule a previously scheduled autosave. commit: 746ac24 746ac24d6edc611c66d8c7ad80b8ea6ee87e1b03 Date: Wed Nov 12 01:32:46 2014 +0000 app-window: Autosave machines when in background When a machine is no longer running in foreground in any window, schedule an autosave for it. commit: 2621d59 2621d593b9b9de643c753cf6219775e9c34000e7 Date: Wed Nov 12 13:08:45 2014 +0000 vm-creator: Add 'expess_install' property Add a convenient property to find out if vm-creator is doing (or going to do) an express installation. commit: 03c829f 03c829fa17c8a1a19dd51344d36abd856b2b7b44 Date: Wed Nov 12 13:24:57 2014 +0000 machine: Add protected 'should_save' property Allow subclasses to easily override the decision to autosave or not. commit: 0627b89 0627b890862ca5be60b602a7934ae6be969df3a7 Date: Wed Nov 12 13:34:24 2014 +0000 libvirt-machine: Don't autosave express installs Express installations are supposed to run in the background since the whole point of it is for user to not interact with the box until installation is complete. commit: 72873c7 72873c7b5012264628592f87a5212c5bf14adac4 Date: Wed Nov 12 14:09:15 2014 +0000 vm-creator: Autosave VM after express install While it doesn't make sense to autosave the VM while express installation is going on in it, we should autosave it once express installation is finished.