GNOME Bugzilla – Bug 760692
Boxes forgot 'run in background' setting for VM
Last modified: 2016-09-20 08:15:55 UTC
Yesterday I turned on the 'run in background' setting for two of my VMs, closed Boxes, and was happy to see they kept running in the background so I could SSH into them. Today when I closed boxes, the VM got suspended. I discovered that the run in background setting I had toggled the day before had been unexpectedly forgotten, so I set it again. Now it seems to be working again... for now.
(In reply to Michael Catanzaro from comment #0) > I discovered that the run > in background setting I had toggled the day before had been unexpectedly > forgotten, so I set it again. By the way, this setting was forgotten for BOTH of the VMs that I set it on.
Half an hour later, I discovered my VM had been suspended even though the setting was enabled when I closed Boxes. The setting was, again, reset to off. In each case, when I reopened Boxes, it had forgotten all my VMs due to Red Hat #1271183.
(In reply to Michael Catanzaro from comment #2) > Half an hour later, I discovered my VM had been suspended even though the > setting was enabled when I closed Boxes. The setting was, again, reset to > off. Eh, half an hour later, I discovered my VM had been suspended even though Boxes was open (but minimized) and I had not changed the value of the setting. Weird....
Hm.. I've been trying to reproduce here but no luck. Is it possible that it's a symptom of https://bugzilla.redhat.com/show_bug.cgi?id=1271183 ? Or this could be another regression that moved configuration files to .cache at some point. Did you happen to clear your .cache around the time this happened?
(In reply to Zeeshan Ali (Khattak) from comment #4) > Or this could be another regression that moved configuration files to .cache > at some point. Did you happen to clear your .cache around the time this > happened? If this was the case, I just pushed patches to fix this. Please try again with git master?
(In reply to Zeeshan Ali (Khattak) from comment #4) > Hm.. I've been trying to reproduce here but no luck. Is it possible that > it's a symptom of https://bugzilla.redhat.com/show_bug.cgi?id=1271183 ? Maybe? I'll put it on my to-do list to test this again once that bug gets fixed. > Or this could be another regression that moved configuration files to .cache > at some point. Did you happen to clear your .cache around the time this > happened? No, I would not have cleared my cache. g-s-d might have, but not on two consecutive days when I first noticed this issue.
(In reply to Michael Catanzaro from comment #6) > (In reply to Zeeshan Ali (Khattak) from comment #4) > > Hm.. I've been trying to reproduce here but no luck. Is it possible that > > it's a symptom of https://bugzilla.redhat.com/show_bug.cgi?id=1271183 ? > > Maybe? I'll put it on my to-do list to test this again once that bug gets > fixed. I just checked by intentionally putting a bad URL in the configuration of default (libvirt) source and it had the effect of Boxes deleting the configuration for all the boxes. So I'm pretty sure now that this is a symptom of that libvirt bug. I think Boxes should not be removing the configuration on failure to connect to the source so I'll try to fix that bit..
I tested these patches to work but if you can test them too, that would be nice. If you can reproduce that libvirt issue, you just need git master of Boxes. --- commit: f7ba9bf55ca7e2f891c901bada7d33505fb35568 Date: Tue Mar 15 19:24:54 2016 +0000 app: Remove a now redundant null check We moved setup of default source into a separate function a while ago and it's called before setup_sources() so there is no need to check for default source being properly setup at this stage anymore. commit: 7783fd209d013896393d68bd34f58f464b8e11ed Date: Tue Mar 15 19:27:13 2016 +0000 broker: add_source() should be able to fail commit: e57a9cd558224465cdcc5b9dc68a25470a9d5364 Date: Tue Mar 15 19:27:36 2016 +0000 libvirt-broker: Throw error on failure to connect We were happily adding the source even after failing to connect to it, which among other things, meant removal of configuration of all the domains on the source in question.
(In reply to Zeeshan Ali (Khattak) from comment #8) > I tested these patches to work but if you can test them too, that would be > nice. If you can reproduce that libvirt issue, you just need git master of > Boxes. Well, it seems the setting is now properly remembered, so that's good. But the VMs still get suspended when I close Boxes. Is this intentional? It's not what I would expect -- having enabled a run in background setting, I would expect the VM to keep running after closing Boxes until I explicitly power it off somehow.
(In reply to Michael Catanzaro from comment #9) > (In reply to Zeeshan Ali (Khattak) from comment #8) > > I tested these patches to work but if you can test them too, that would be > > nice. If you can reproduce that libvirt issue, you just need git master of > > Boxes. > > Well, it seems the setting is now properly remembered, so that's good. But > the VMs still get suspended when I close Boxes. Is this intentional? It's > not what I would expect -- having enabled a run in background setting, I > would expect the VM to keep running after closing Boxes until I explicitly > power it off somehow. Yes, that is exactly the intended behaviour and it works fine here. Maybe you're hitting some corner case. Was it just one VM or multiple that you have enabled this for? I'm hoping with more details, I can reproduce your issue here.