Bug 973777 - virt-manager enters infinite loop when org.virt-manager.virt-manager.connections uris is unset
virt-manager enters infinite loop when org.virt-manager.virt-manager.connecti...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
19
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-12 13:31 EDT by Zbigniew Jędrzejewski-Szmek
Modified: 2013-06-29 14:14 EDT (History)
5 users (show)

See Also:
Fixed In Version: virt-manager-0.10.0-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-29 14:14:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zbigniew Jędrzejewski-Szmek 2013-06-12 13:31:58 EDT
Description of problem:
I deleted my gnome user settings and had:

$ gsettings get org.virt-manager.virt-manager.connections autoconnect
@as []
$ gsettings get org.virt-manager.virt-manager.connections uris
@as []

Starting virt-manager gives me a window with a moving slider which just waits forever (screenshot attached). Also, the smaller window doesn't have a "close" button, and does not go away when the parent window is closed.

Doing gsettings set org.virt-manager.virt-manager.connections uris "['qemu:///system']" makes virt-manager work again.

Version-Release number of selected component (if applicable):
virt-manager-0.10.0-0.5.gitde1695b2.fc19.noarch

How reproducible:
100%

Steps to Reproduce:
% gsettings set org.virt-manager.virt-manager.connections uris "[]"
% gsettings get org.virt-manager.virt-manager.connections uris
@as []
% virt-manager

Expected results:
Something which doesn't require xkill :)
Comment 1 Cole Robinson 2013-06-13 17:42:48 EDT
virt-manager is talking to packagekit there, so if your yum cache is cold it could take quite a while. Something could be going wrong though. You can easily reproduce with ./virt-manager --debug --test-first-run, I'm interested if there's any error messages shown, or it's just a case of packagekit taking a long time.

The lack of an 'X' button is a side effect of that being a 'dialog' window, I guess gnome policy says no X button now.

However I added the machinery to make the lookup cancellable, so there's a working cancel button now.
Comment 2 Fedora Update System 2013-06-19 19:00:57 EDT
virt-manager-0.10.0-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/virt-manager-0.10.0-1.fc19
Comment 3 Zbigniew Jędrzejewski-Szmek 2013-06-20 10:02:19 EDT
Hm, I've alrady given +1 karma, but now I see that "cancel" doesn't seem to work :( Pressing it doesn't seem to have any effect.

(In reply to Cole Robinson from comment #1)
> virt-manager is talking to packagekit there, so if your yum cache is cold it
> could take quite a while. Something could be going wrong though. You can
> easily reproduce with ./virt-manager --debug --test-first-run, I'm
> interested if there's any error messages shown, or it's just a case of
> packagekit taking a long time.
I might be that. If I do "sudo bash -c 'echo 3 > /proc/sys/vm/drop_caches'" then virt-manager takes about a minute to start now.

> The lack of an 'X' button is a side effect of that being a 'dialog' window,
> I guess gnome policy says no X button now.
> 
> However I added the machinery to make the lookup cancellable, so there's a
> working cancel button now.
Unfortunately it doesn't seem to work.
Comment 4 Cole Robinson 2013-06-20 10:33:03 EDT
It's working for me but the mechanism isn't too responsive. Try this:

- remove libvirt\*
- drop caches
- virt-manager --debug --test-first-run
- click cancel
- dialog still sticks around for a bit, but finally closes. notice it never shows the 'these packages need to be installed' dialog so the process was actually cancelled.

Once you click cancel it is out of our hands into dbus/packagekit hands. But we could make it appear to cancel faster by closing the dialog and continuing on immediately after the cancel button is clicked, even though packagekit is still chugging away. that fix is a bit more involved though.
Comment 5 Zbigniew Jędrzejewski-Szmek 2013-06-20 10:56:32 EDT
(In reply to Cole Robinson from comment #4)
> Once you click cancel it is out of our hands into dbus/packagekit hands. But
> we could make it appear to cancel faster by closing the dialog and
> continuing on immediately after the cancel button is clicked, even though
> packagekit is still chugging away. that fix is a bit more involved though.
Hm, yes, I see:

2013-06-20 10:37:47,975 (packageutils:46): Asking PackageKit what's installed locally.
2013-06-20 10:37:47,986 (asyncjob:190): Creating async job for function cb=<function _do_async_search at 0x2e097d0>
2013-06-20 10:37:48,943 (packageutils:127): Package search cancelled by user
...
2013-06-20 10:37:54,337 (connection:1020): User cancelled auth, not raising any error.

So indeed "cancel" has an effect.

> It's working for me but the mechanism isn't too responsive. Try this:
> 
> - remove libvirt\*
> - drop caches
> - virt-manager --debug --test-first-run
> - click cancel
> - dialog still sticks around for a bit, but finally closes. notice it never
> shows the 'these packages need to be installed' dialog so the process was
> actually cancelled.

I tried that, and I think I found another thing which could be improved:
If I just 'systemctl stop libvirtd', then virt-manager attempts to start it, but that doesn't work:

2013-06-20 10:37:31,588 (packageutils:201): Trying to start libvirtd through systemd
2013-06-20 10:37:31,595 (packageutils:226): libvirtd state='inactive'
2013-06-20 10:37:31,595 (packageutils:236): libvirtd not running, asking system-config-services to start it
2013-06-20 10:37:31,597 (packageutils:247): Failed to talk to system-config-services
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/packageutils.py", line 242, in start_libvirtd
    scs.StartUnit("(ss)", unitname, "replace")
  File "/usr/lib64/python2.7/site-packages/gi/overrides/Gio.py", line 171, in __call__
    None)
  File "/usr/lib64/python2.7/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
GError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.fedoraproject.Config.Services was not provided by any .service files
2013-06-20 10:37:34,186 (manager:213): Closing manager

That's because I don't have system-config-services installed. Unfortunatly, the error message is misleading: virt-manager says

      Libvirt service must be started

      virt-manager will connect to libvirt on the next application start up.

but that's not true — if I start virt-manager again, I get the same error.

Maybe it would be better to have libvirt socket activated (on '/var/run/libvirt/libvirt-sock') by systemd directly and avoid system-config-services?
Comment 6 Fedora Update System 2013-06-20 14:00:25 EDT
Package virt-manager-0.10.0-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing virt-manager-0.10.0-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11349/virt-manager-0.10.0-1.fc19
then log in and leave karma (feedback).
Comment 7 Cole Robinson 2013-06-24 12:28:25 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> 
> That's because I don't have system-config-services installed. Unfortunatly,
> the error message is misleading: virt-manager says
> 
>       Libvirt service must be started
> 
>       virt-manager will connect to libvirt on the next application start up.
> 
> but that's not true — if I start virt-manager again, I get the same error.
> 

Indeed, I tweaked this dialog message upstream, thanks for noticing.

> Maybe it would be better to have libvirt socket activated (on
> '/var/run/libvirt/libvirt-sock') by systemd directly and avoid
> system-config-services?

It's in kind of a weird spot here. libvirt is one of the services that is systemctl enable'd by default, since it needs to run at host startup so VMs are autostarted, etc. But it isn't started on initial install. Socket activation would seamlessly fix the first install case but not sure if the effort is worth it.
Comment 8 Daniel Berrange 2013-06-24 12:33:53 EDT
(In reply to Cole Robinson from comment #7)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> > Maybe it would be better to have libvirt socket activated (on
> > '/var/run/libvirt/libvirt-sock') by systemd directly and avoid
> > system-config-services?
> 
> It's in kind of a weird spot here. libvirt is one of the services that is
> systemctl enable'd by default, since it needs to run at host startup so VMs
> are autostarted, etc. But it isn't started on initial install. Socket
> activation would seamlessly fix the first install case but not sure if the
> effort is worth it.

We can't rely on socket activation at nomral boot, since libvirtd must always start in order to process any guests (or other objects) marked as 'autostart'.

We could still enable socket activation, such that libvirtd gets started if an app connects after RPM install, but prior to reboot, provided we ensure it unconditionally starts on normal boot.

The other option is to move the handling of the 'autostart' code out of libvirtd and into the libvirt-guests init script, so that libvirtd only get auto-started if there was actually a guest which needed autostart. That's kind of backwards from where we would like to go though - we want to move the libvirt-guests init code into libvirtd instead.
Comment 9 Zbigniew Jędrzejewski-Szmek 2013-06-24 13:00:45 EDT
(In reply to Daniel Berrange from comment #8)
> (In reply to Cole Robinson from comment #7)
> > (In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> > > Maybe it would be better to have libvirt socket activated (on
> > > '/var/run/libvirt/libvirt-sock') by systemd directly and avoid
> > > system-config-services?
> > 
> > It's in kind of a weird spot here. libvirt is one of the services that is
> > systemctl enable'd by default, since it needs to run at host startup so VMs
> > are autostarted, etc. But it isn't started on initial install. Socket
> > activation would seamlessly fix the first install case but not sure if the
> > effort is worth it.
> 
> We can't rely on socket activation at nomral boot, since libvirtd must
> always start in order to process any guests (or other objects) marked as
> 'autostart'.
> 
> We could still enable socket activation, such that libvirtd gets started if
> an app connects after RPM install, but prior to reboot, provided we ensure
> it unconditionally starts on normal boot.
Simply allowing socket activated start in addition to the current activation on boot (as part of multi-user.target) should work. libvirtd.service will be spawned when either of the two events happens.
Comment 10 Fedora Update System 2013-06-29 14:14:21 EDT
virt-manager-0.10.0-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.