Red Hat Bugzilla – Bug 459665
root consolehelper breaks remote ssh virt-manager/libvirtd connections
Last modified: 2009-07-15 04:21:15 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):
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)
virt-manager will report an error. The details will show python exceptions pointing to a "connection reset by peer" error.
virt-manager should connect without issue
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..
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)?
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.
- 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
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...
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.
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.
When I run unprivileged I get prompted for an ssh password but not when running virt-manager privileged.
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
I'm experiencing the same problem on my F10 system.
I suspect these instructions will solve your problem:
cheers ... david
*** Bug 477101 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 485564 has been marked as a duplicate of this bug. ***
*** Bug 475594 has been marked as a duplicate of this bug. ***
virt-manager-0.6.1-1.fc9 has been submitted as an update for Fedora 9.
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
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
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.
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
Removing needinfo flag
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:
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.
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.