Bug 1035368

Description of problem:
Additionally to Bugs 872166 and 986365 reporting that the virsh / virt-manager
infrastructure does not work without an authentication agent now (in earlier
versions this was working) it does not work without dbus-daemon either.

The only way to successfully start virt-manager is to start it locally
on the machine, where libvirtd is running, in a GNOME or other session,
that starts dbus-daemon. No way to make all needed things work from remote.
It's more and more broken failing in different ways showing more and more
dependencies.

If it needs an authentication agent, why doesn't it start one.
If it needs dbus-daemon, it should start one. Maybe this works, but
within the first hours after a host system boot it doesn't.

Scenarios and how they fail:
1) ssh -l root remote-system (DISPLAY tunneling, or setting DISPLAY to
the remote system address does not matter) and start virt-manager:
ERROR popup, no password prompted:
--------------------------------------------------------------------------
Error starting Virtual Machine Manager: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: Failed to connect to socket /tmp/dbus-92vjx9L6ca: Connection refused)

Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-manager.py", line 383, in <module>
    main()
  File "/usr/share/virt-manager/virt-manager.py", line 315, in main
    config = virtManager.config.vmmConfig(appname, appversion, glade_dir)
  File "/usr/share/virt-manager/virtManager/config.py", line 98, in __init__
    self.conf.add_dir(self.conf_dir, gconf.CLIENT_PRELOAD_NONE)
GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details -  1: Failed to get connection to session: Failed to connect to socket /tmp/dbus-92vjx9L6ca: Connection refused)
--------------------------------------------------------------------------
Notes: Where does it have this /tmp/dbus-92vjx9L6ca ? There is no dbus-daemon running on the remote system. The libvirtd is of course running.

2) Going as normal user to the remote system with ssh and starting virt-manager the same happens immediately.

After a while of runtime (a day or so) the scenario 2) changes (no idea why) and the following is seen.

3) Going to the remote system via ssh without RSA authentication as non-root and starting virt-manager:
A popup appears to ask for a password. Whatever i enter here (my password or the root password), it does not work.
I get several popups:
--------------------------------------------------------------------------
SSH password dialog could not grab the keyboard input.
This might be caused by application such as screensaver, however it could also mean that someone may be eavesdropping on your session.
Either close the application which grabs the keyboard or log out and log in again to prevent this from happening.
Unable to open a connection to the libvirt management daemon.
--------------------------------------------------------------------------

In the syslog i see:
sshd[27382]: error: PAM: Authentication failure for root from myhost.domain.org

This applies for connections of type ssh. For connections of type qemu:///system
the known authentication daemon thing is barfed:
--------------------------------------------------------------------------
Libvirt URI is: qemu+ssh://root@virthost/system

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

authentication failed: Authorization requires authentication but no agent is available.

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1154, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 1138, in _try_open
    flags)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed: Authorization requires authentication but no agent is available.
--------------------------------------------------------------------------

4) going to the host via ssh and using password-free RSA authentication (ssh-agent), then start virt-manager

I really get the virt-manager up and connecting virtual hosts with ssh-type
connections.
But as said above, i have to wait for this to work for a day or longer after
a host system boot.
Now virt-manager seems to start a dbus-daemon itself. Connections of type
qemu:///system still do not work at all.

5) Running virt-manager locally and using a connection of type ssh to the machine, where the virtual systems are running, with password-less (ssh-agent) RSA

Works (also only if password-less, entering passwords fails), but the console
cannot be connected without permitting the VNC connections from remote via
TCP, what i do not want and what is not the default.

Version-Release number of selected component (if applicable):
0.9.0-18.el6.x86_64

How reproducible:
see above

Actual results:
virt-manager works the way i (and quite likely not only me) want
it to be used only after a day or more and does never work, when
a password must be given, especially not with ssh type connections

Expected results:
virt-manager also works when started as root, immediately, when
the hosting system has booted (an not having to wait a day or more)
and also, when a password must be given.

Additional info:
Scenarios 3) and 4) succeeded and 2) did work supplying the root password in
the dialog until the RPM update to the current versions of kernel and
KVM/QEMU components, it also worked immediately after host system startup.
Scenario 1) succeeded after a day or so of host system uptime
until the RPM update.
Did not try 5) with the old RPM update status, but this is not relevant.
With the old RPM versions connections of tyep qemu:///system in general
worked as root, now don't seem to work anymore at all.
The previous RPM update status dated to the versions current around
May 2013