qemu:///sessions fail, when libvirtd hasn't been started properly before

Impact:
clients using qemu:///session fail to contact the server, that makes e.g gnome-boxes fail to work correctly

Test case:
- run "virsh -c qemu:///session"

it hits this in quantal "error: failed to connect to the hypervisor", with the fix it should work

Regression potential:
Limited, that commit is only setting some extra environment variables

-----

Starting with 12.10 the libvirt communications mechanism uses the "XDG_RUNTIME_DIR" environment variable to determine the directory to put in its pipe(s) and controlling files - this normally being "/run/user/$USER/libvirt".

Now when you run a qemu user(!) session (qemu:///session) and a 'libvirtd'-process owned by the user hasn't already be spawned - e.g. manually - libvirt0 will spawn one itself. When manually spawned from a terminal window, "XDG_RUNTIME_DIR" is properly set up to "/run/user/$USER" and everything works well with libvirtd. When libvirt0 spawns the libvirtd, it will use $HOME/.cache/libvirt, the previous (up to and including 12.04) location for this, because this seems to be its fallback-default.

Thus when you start such a session with "virsh -c qemu:///session" or vitual-manager, respectively, it will fail, saying

error: Failed to connect socket to '/run/user/$USER/libvirt/libvirt-sock': No such file or directory
error: failed to connect to the hypervisor

in the former case.

Either "XDG_RUNTIME_DIR" is not properly set when libvirt spawns libvirtd, or it is not respected. My assumption is the former, as "XDG_RUNTIME_DIR" seems to be set by some 'pam'-module, that probably isn't used when libvirt exececutes libvirtd.

As a workaround one can set "XDG_RUNTIME_DIR=.cache" in the environment calling "virsh" or "virtual-manager", the everything uses the old/former settings and works.

The problem seems to be to tell libvirt about the proper "XDG_RUNTIME_DIR" contents or make it the new default.

The way it is now, qemu-user-sessions will just fail when started by virsh or virt-manager.

By the way, you can test it even with a 'live'-system (USB/DVD) by just adding the libvirt-bin and/or virt-manager packages, thus it is not dependent on the version of the packages installed on the actual system.

Nevertheless as I can't see if that information is attached otherwise, here are the system data you require:
Description: Ubuntu 12.10
Release: 12.10
libvirt0:
  Installed: 0.9.13-0ubuntu12
  Candidate: 0.9.13-0ubuntu12
  Version table:
 *** 0.9.13-0ubuntu12 0
        500 http://de.archive.ubuntu.com/ubuntu/ quantal/main i386 Packages
        100 /var/lib/dpkg/status

Best regards.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: libvirt0 0.9.13-0ubuntu12
ProcVersionSignature: Ubuntu 3.5.0-17.28-generic 3.5.5
Uname: Linux 3.5.0-17-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu6
Architecture: i386
Date: Fri Nov 2 17:13:51 2012
InstallationDate: Installed on 2011-03-05 (608 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007.1)
MarkForUpload: True
SourcePackage: libvirt
UpgradeStatus: Upgraded to quantal on 2012-10-26 (6 days ago)