Bug 459665

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
libvirt-0.4.6-2.fc9.x86_64
libvirt-python-0.4.6-2.fc9.x86_64
python-virtinst-0.300.3-7.fc9.noarch
virt-manager-0.5.4-5.fc9.x86_64
virt-viewer-0.0.3-1.fc9.x86_64
virt-top-1.0.1-4.fc9.x86_64

On the server I have:
# rpm -qa | grep virt
virt-viewer-0.0.3-1.fc9.x86_64
libvirt-0.4.6-2.fc9.x86_64
python-virtinst-0.300.3-7.fc9.noarch
virt-manager-0.5.4-5.fc9.x86_64
libvirt-python-0.4.6-2.fc9.x86_64

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

Details:
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...

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
virt-manager-0.6.0-5.fc10.i386
libvirt-0.5.1-2.fc10.i386
libvirt-python-0.5.1-2.fc10.i386
virt-viewer-0.0.3-3.fc10.i386
python-virtinst-0.400.0-5.fc10.noarch

I'm experiencing the same problem on my F10 system.

I suspect these instructions will solve your problem:

http://virt-manager.et.redhat.com/page/RemoteSSH

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:

http://kojipkgs.fedoraproject.org/packages/virt-manager/0.6.1/2.fc11/src/virt-manager-0.6.1-2.fc11.src.rpm
http://kojipkgs.fedoraproject.org/packages/python-virtinst/0.400.1/1.fc11/src/python-virtinst-0.400.1-1.fc11.src.rpm

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.
http://admin.fedoraproject.org/updates/virt-manager-0.6.1-1.fc9

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__
    self.prepare_hw_list()
  File "/usr/share/virt-manager/virtManager/details.py", line 1504, in prepare_hw_list
    self.populate_hw_list()
  File "/usr/share/virt-manager/virtManager/details.py", line 1526, in populate_hw_list
    self.repopulate_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

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.