Bug 459665 - root consolehelper breaks remote ssh virt-manager/libvirtd connections
root consolehelper breaks remote ssh virt-manager/libvirtd connections
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cole Robinson
Fedora Extras Quality Assurance
: 475594 477101 485564 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-08-20 18:04 EDT by Paul B Schroeder
Modified: 2009-07-15 04:21 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-15 04:21:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul B Schroeder 2008-08-20 18:04:59 EDT
Description of problem:
Did a yum update and got the latest version of virt-manager (0.5.4-4.fc9) in the updates repo.  Afterwords, I was not able to connect via qemu+ssh (qemu+ssh://root@myhost/system).  I was seeing "connection reset by peer" errors.  Downgrading to the base F9 package version (0.5.4-3.fc9.x86_64) resolved the issue.

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

How reproducible:
Install the latest virt-manager available in the yum repos and try to connect to a remote libvirtd via qemu through a ssh tunnel.

Steps to Reproduce:
1. yum update
2. start virt-manager
3. create a new connection (qemu+ssh)
Actual results:
virt-manager will report an error.  The details will show python exceptions pointing to a "connection reset by peer" error.

Expected results:
virt-manager should connect without issue

Additional info:
Comment 1 Paul B Schroeder 2008-08-22 15:52:04 EDT
Looks as if it works fine when running latest virt-manager (virt-manager-0.5.4-4.fc9.x86_64) from the command line as root.  Problem occurs when running as a regular user, even though it authenticated me just fine..
Comment 2 Cole Robinson 2008-10-23 15:29:15 EDT
Hmm, I really can't reproduce this. Sure it wasn't just a one off error? Nothing relevant changed between the two virt-manager versions. Could it have been libvirt dependent?

If it's reproducable, how are you invoking the application when it fails (menu, command line)?
Comment 3 Paul B Schroeder 2008-10-23 17:40:14 EDT
I'm pretty sure it's not a one off error.  My colleague was also experiencing the same issue.  And I'm still having issues.  FYI, at the moment, on the client I have:
# rpm -qa | grep virt

On the server I have:
# rpm -qa | grep virt

As mentioned above, it works just fine when I "su -" to root and execute virt-manager from the command line.

The problem occurs when I start it as a regular user.  Either via the command line, using the menus in gnome, or if I start it via "Run Virtual Machine Manager..." from the gnome applet.

When I start it as my "normal" user, it brings up the dialog to ask me for the root password (or run unprivileged).  Everything looks fine at that point. I right click on the host name I wish to connect to and click "Connect".  It doesn't prompt me for the root password to the remote libvird host.  It brings up an error dialog immediately.

Here's the dialog I get:

Unable to open a connection to the libvirt management daemon.

Verify that:
- The 'libvirtd' daemon has been started

Unable to open connection to hypervisor URI 'qemu+ssh://root@cantona/system':
<class 'libvirt.libvirtError'> Connection reset by peer
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 439, in _open_thread
    None], flags)
  File "/usr/lib64/python2.5/site-packages/libvirt.py", line 99, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Connection reset by peer

Hope the extra details help...
Comment 4 Cole Robinson 2008-10-24 09:50:04 EDT
Hmm, interesting. Just to verify, when the 'Run unprivileged' dialog pops up you are selecting 'Run unprivileged' or entering the root password?

From the command line, can you try 

'virsh --connect qemu+ssh://root@cantona/system'

as both a regular user and su - and report the results? Thanks.
Comment 5 Paul B Schroeder 2008-10-24 12:14:28 EDT
I am entering the root password and clicking the "OK" button.

Doing 'virsh --connect qemu+ssh://root@cantona/system' from the command line seems to work fine either way.
Comment 6 Jens Petersen 2008-11-20 01:51:56 EST
When I run unprivileged I get prompted for an ssh password but not when running virt-manager privileged.
Comment 7 Rob Strong 2009-01-06 14:44:16 EST
I'm working on a small project using Fedora 10 and having the same exact problems.  When I run virt-manager as a normal user and type in the root password I can not connect to a system remotely using ssh.  I can use the virsh command line as you suggested in comment 5.

[root@rstrong-lt ~]# rpm -qa | grep virt
Comment 8 Dennis Jacobfeuerborn 2009-02-04 09:39:27 EST
I'm experiencing the same problem on my F10 system.
Comment 9 David Cartwright 2009-02-07 03:52:12 EST
I suspect these instructions will solve your problem:


cheers ... david
Comment 10 Cole Robinson 2009-02-08 17:16:27 EST
*** Bug 477101 has been marked as a duplicate of this bug. ***
Comment 11 Cole Robinson 2009-02-08 17:22:06 EST
This all stems from funkiness using consolehelper to give root privs at application startup. We use PolicyKit in f9 and f10 to handle connecting to libvirt with neccessary privs, which is a lot nicer than running the whole app as root.

So the solution here is to kill off consolehelper, meaning no 'Enter root password or run unprivileged' dialog when the app starts, but you will see a 'Enter root password' if trying to connect to a local qemu:///system for example.

I'll do this shortly in rawhide, and when we push virt-manager 0.6.1 to f10 (and possibly f9) I'll make the change there as well.

The workaround in the interim as people have noted, is to always select 'Run Unprivileged' (preferred) or launch the app from the command line as root.
Comment 12 Jan "Yenya" Kasprzak 2009-02-12 10:47:48 EST
I have just downloaded the following src.rpm packages from Koji, rebuilt them on F10, installed, and now remote qemu+ssh connections work for me:


So I would say these packages can be pushed as F10 (and probably F9 as well) updates.
Comment 13 Cole Robinson 2009-02-15 12:14:41 EST
*** Bug 485564 has been marked as a duplicate of this bug. ***
Comment 14 Cole Robinson 2009-02-15 12:15:56 EST
*** Bug 475594 has been marked as a duplicate of this bug. ***
Comment 15 Fedora Update System 2009-03-04 14:21:43 EST
virt-manager-0.6.1-1.fc9 has been submitted as an update for Fedora 9.
Comment 16 Dennis Jacobfeuerborn 2009-03-04 15:11:26 EST
I just updated to the lates koji build for f10. Now I can connect create ssh connections again but when I try to access a VM I get the following:

Error bringing up domain details: Error parsing domain xml: 'NoneType' object is not iterable

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 272, in show_details
    details = vmmDetails(self.get_config(), con.get_vm(uuid), self)
  File "/usr/share/virt-manager/virtManager/details.py", line 332, in __init__
  File "/usr/share/virt-manager/virtManager/details.py", line 1504, in prepare_hw_list
  File "/usr/share/virt-manager/virtManager/details.py", line 1526, in populate_hw_list
  File "/usr/share/virt-manager/virtManager/details.py", line 1618, in repopulate_hw_list
    for charinfo in self.vm.get_char_devices():
  File "/usr/share/virt-manager/virtManager/domain.py", line 806, in get_char_devices
    return self._parse_device_xml(_parse_char_devs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 913, in _parse_device_xml
    raise RuntimeError(_("Error parsing domain xml: %s") % str(e))
RuntimeError: Error parsing domain xml: 'NoneType' object is not iterable
Comment 17 Cole Robinson 2009-03-04 18:26:40 EST
Can you paste the offending VMs xml? You can use 'virsh dumpxml vmname'

Does this only happen with 1 VM, or all of them? I'll try and reproduce.
Comment 18 Fedora Update System 2009-03-05 11:27:33 EST
virt-manager-0.6.1-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update virt-manager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2380
Comment 19 Mark McLoughlin 2009-04-20 05:59:10 EDT
Removing needinfo flag
Comment 20 Bug Zapper 2009-06-09 22:31:21 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 21 Jan "Yenya" Kasprzak 2009-06-18 05:37:34 EDT
I don't see this problem in F11 (virt-manager-0.7.0-5.fc11.x86_64), so this has probably been fixed in the meantime.
Comment 22 Bug Zapper 2009-07-15 04:21:15 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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