Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1045033 - LIBVIRT_DEFAULT_URI=qemu:///system breaks libguestfs
Summary: LIBVIRT_DEFAULT_URI=qemu:///system breaks libguestfs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libguestfs
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1045069
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2013-12-19 13:43 UTC by Richard W.M. Jones
Modified: 2014-01-30 03:38 UTC (History)
13 users (show)

Fixed In Version: libguestfs-1.24.5-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1045069 (view as bug list)
Environment:
Last Closed: 2014-01-30 03:38:48 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Richard W.M. Jones 2013-12-19 13:43:34 UTC
Description of problem:

Stefan had this environment variable set:
LIBVIRT_DEFAULT_URI=qemu:///system

This breaks libguestfs, eg:

$ libguestfs-test-tool

[...]

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
 [code=1 domain=10]

Version-Release number of selected component (if applicable):

libvirt-daemon-1.1.3-2.fc21.x86_64

How reproducible:

100%

Steps to Reproduce:
1. As above.

Comment 1 Daniel Berrangé 2013-12-19 13:51:59 UTC
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.

Comment 2 Richard W.M. Jones 2013-12-19 14:09:21 UTC
(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:
http://libvirt.org/drvqemu.html#uris
doesn't reflect the reality.  (But it would be nice if root
had session guests).

Comment 3 Daniel Berrangé 2013-12-19 14:11:24 UTC
If libguestfs is running as root then there is no qemu:///session instance you can use - qemu:///system is your only choice.

Comment 4 Daniel Berrangé 2013-12-19 14:37:22 UTC
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.

Comment 5 Richard W.M. Jones 2013-12-19 14:47:43 UTC
Patch posted for this bug here:
https://www.redhat.com/archives/libguestfs/2013-December/msg00085.html

Comment 6 Fedora Update System 2014-01-21 08:44:33 UTC
libguestfs-1.24.5-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libguestfs-1.24.5-1.fc20

Comment 7 Fedora Update System 2014-01-22 03:10:47 UTC
Package libguestfs-1.24.5-1.fc20:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2014-1262/libguestfs-1.24.5-1.fc20
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2014-01-30 03:38:48 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.