Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1576819 - virt-manager unable to connect to libvirt
Summary: virt-manager unable to connect to libvirt
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Cole Robinson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-10 12:56 UTC by Louis van Dyk
Modified: 2018-07-10 10:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-10 10:00:04 UTC
Type: Bug


Attachments (Terms of Use)

Description Louis van Dyk 2018-05-10 12:56:44 UTC
Description of problem:
Normally, when opening virt-manager, I am prompted for my user's password, and then virt-manager is connected to QEMU/KVM.  However, as of the last few days, I am never prompted for my username, and I get the message below after 30 seconds.

Restarting the libvirtd service does not help, nor does rebooting.  I can start a VM using virsh, but this doesn't help much since I cannot interact with the VM.

Here is the pop-up error message:

Unable to connect to libvirt.

error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1035, in _do_open
    self._backend.open(self._do_creds_password)
  File "/usr/share/virt-manager/virtinst/connection.py", line 144, in open
    open_flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.



Version-Release number of selected component (if applicable):

virt-manager-1.4.3-2.fc27.noarch
virt-manager-common-1.4.3-2.fc27.noarch

How reproducible:
Open virt-manager from the GUI or the command line.  Wait.  Error pops up.

Steps to Reproduce:
1. As above
2.
3.

Actual results:

[louis@fedora ~]$ virt-manager --debug
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (cli:264) Launched with command line: /usr/share/virt-manager/virt-manager --debug
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (virt-manager:185) virt-manager version: 1.4.3
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (virt-manager:186) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (virt-manager:216) PyGObject version: 3.26.1
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (virt-manager:220) GTK version: 3.22.26
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (engine:497) libguestfs inspection support: False
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (systray:74) Using AppIndicator3 for systray
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (systray:156) Showing systray: False
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (engine:1032) processing cli command uri= show_window= domain=
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (engine:1034) No cli action requested, launching default window
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (manager:203) Showing manager
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (engine:402) window counter incremented to 1
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (engine:161) Loading stored URIs:
qemu:///system
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (engine:140) Initial gtkapplication activated
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (connection:602) conn=qemu:///system changed to state=Connecting
[Thu, 10 May 2018 14:50:11 virt-manager 35666] DEBUG (connection:1019) Scheduling background open thread for qemu:///system


[Thu, 10 May 2018 14:50:41 virt-manager 35666] DEBUG (connection:602) conn=qemu:///system changed to state=Disconnected
[Thu, 10 May 2018 14:50:41 virt-manager 35666] DEBUG (error:99) error dialog message:
summary=Unable to connect to libvirt.

error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
details=Unable to connect to libvirt.

error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1035, in _do_open
    self._backend.open(self._do_creds_password)
  File "/usr/share/virt-manager/virtinst/connection.py", line 144, in open
    open_flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[Thu, 10 May 2018 14:50:52 virt-manager 35666] DEBUG (manager:214) Closing manager
[Thu, 10 May 2018 14:50:52 virt-manager 35666] DEBUG (engine:406) window counter decremented to 0
[Thu, 10 May 2018 14:50:52 virt-manager 35666] DEBUG (engine:468) No windows found, requesting app exit
[Thu, 10 May 2018 14:50:52 virt-manager 35666] DEBUG (engine:492) Exiting app normally.





Unable to connect to libvirt.

error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1035, in _do_open
    self._backend.open(self._do_creds_password)
  File "/usr/share/virt-manager/virtinst/connection.py", line 144, in open
    open_flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: error from service: CheckAuthorization: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Expected results:
I should be requested to enter my user's password, and then virt-manager should display the VM's on my system.

Additional info:

Comment 1 Cole Robinson 2018-05-10 16:29:14 UTC
Sounds like it could be https://bugzilla.redhat.com/show_bug.cgi?id=1568213 but that was on f28 only... after a reboot does it work? does it then break if you cancel auth at any point? maybe f27 needs a fix backported

Comment 2 Louis van Dyk 2018-05-11 03:02:25 UTC
Hmm.  So yes.  It works 100% after a reboot.  ("Have you turned if off an on again" comes to mind!)  
BUT, I haven't yet been able to break it again.  So I don't know what caused it initially.  The host uptime was around a day when it occurred.
I will update this again if it breaks.

Comment 3 Louis van Dyk 2018-07-10 10:00:04 UTC
This problem has not re-occurred.  I think we can close this.


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