Description of problem:
Stefan had this environment variable set:
This breaks libguestfs, eg:
libguestfs: error: could not create appliance through libvirt.
Try using the direct backend to run qemu directly without libvirt,
by setting the LIBGUESTFS_BACKEND=direct environment variable.: internal error: process exited while connecting to monitor: qemu-system-x86_64: -chardev socket,id=charserial0,path=/tmp/libguestfsB40jqN/console.sock: Failed to connect to socket: Permission denied
qemu-system-x86_64: -chardev socket,id=charserial0,path=/tmp/libguestfsB40jqN/console.sock: chardev: opening backend "socket" failed
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. As above.
Why is libguestfs relying on automatic probing of libvirt URIs ? This is only suitable for applications which are able to run against any libvirt virtualization driver - there's no guarantee it'll even be QEMU. Libguestfs should explicitly request qemu:///session if non-root, or qemu:///system if running as root.
(In reply to Daniel Berrange from comment #1)
> Why is libguestfs relying on automatic probing of libvirt URIs ? This is
> only suitable for applications which are able to run against any libvirt
> virtualization driver - there's no guarantee it'll even be QEMU. Libguestfs
> should explicitly request qemu:///session if non-root, or qemu:///system if
> running as root.
Isn't qemu:///system always wrong? It has caused us a lot of
trouble in the past, eg: bug 913774, bug 984409. Why can't
we always specify qemu:///session?
Also I'd say the documentation here:
doesn't reflect the reality. (But it would be nice if root
had session guests).
If libguestfs is running as root then there is no qemu:///session instance you can use - qemu:///system is your only choice.
NB, I'm not entirely against the idea of introducing a way to use 'qemu://session' when running as root. The distinction of system vs session was motivated by the way dbus separates its system and session bus. When run as root, dbus still allows creation of a session bus for root.
We've got a long historical practice where libvirtd uses getuid==0 to determine whether it runs in system vs session mode, so we'd need to some flag to force it to use session mode. We then also probably need to audit every single piece of code which looks as 'bool privileged' to see that it still makes sense when running in session mode as root.
Patch posted for this bug here:
libguestfs-1.24.5-1.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libguestfs-1.24.5-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
libguestfs-1.24.5-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.