Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #1075164 +++
virt-manager opens its own libvirt connection, which does all the necessary polkit or remote auth. Ideally we could then pass that connection to libguestfs to use for inspecting our vms.
Coupled with using the libvirt stream APIs to upload the guest appliance to /var/lib/libvirt/images or similar, this would allow the unprivileged virt-manager instance to inspect root owned guest images, and even work for remote connections.
--- Additional comment from Richard W.M. Jones on 2014-03-27 19:11:20 UTC ---
Typical error would be:
[Thu, 27 Mar 2014 13:56:47 virt-manager 6941] ERROR (inspection:158) qemu:///system:F20: exception while processing
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/inspection.py", line 148, in _process_vms
data = self._process(conn, vm, vmuuid)
File "/usr/share/virt-manager/virtManager/inspection.py", line 193, in _process
g.launch()
File "/usr/lib/python2.7/site-packages/guestfs.py", line 323, in launch
r = libguestfsmod.launch (self._o)
RuntimeError: could not create appliance through libvirt.
Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct
Original error from libvirt: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/var/lib/libvirt/images/f20-stack.qcow2': Operation not permitted [code=38 domain=24]
Because libguestfs is not using the same libvirt context, it
is unable to set SELinux labels on root-owned files in /var/lib/libvirt.
--- Additional comment from Richard W.M. Jones on 2014-05-15 08:39:36 UTC ---
I ought to write a few words about why this is difficult ...
It would be nice to pass an opened libvirt domain (virDomainPtr)
to libguestfs API calls, ie. code like this:
guestfs_h *g = guestfs_create ();
guestfs_add_libvirt_dom (g, dom);
guestfs_launch ();
In fact libguestfs internally has a 'guestfs_add_libvirt_dom'
method (or its equivalent, it's not called that precisely) but it
is not exported in the public API.
We could, relatively easily, export that through the C API.
The problem comes with language bindings. How would we implement
(eg) Python:
dom = conn.lookupByName ("guest")
g = guestfs.GuestFS ()
g.add_libvirt_dom (dom)
g.launch ()
Libguestfs would have to know somehow about the internal
C representation of the libvirt python bindings' "dom" object
in order to be able to take a "dom" and turn it into a
virDomainPtr. (And because that representation is internal
to libvirt, it might change in future, leading to strange bugs).
Implemented upstream by v1.2.11:
commit e3da7ade421a1fbb5f1789dea9903a3ae6243ced
Author: Richard W.M. Jones <rjones>
Date: Thu Dec 11 11:16:12 2014 +0000
Add c_pointer method to classes.
This returns the raw C pointer to the underlying object, eg:
conn = libvirt.open(None)
print "0x%x" % conn.c_pointer() # returns virConnectPtr of the connection
dom = conn.lookupByName("test")
print "0x%x" % dom.c_pointer() # returns virDomainPtr of the domain
The reason behind this is to allow us to transparently pass Python dom
objects through the libguestfs Python API.
https://bugzilla.redhat.com/show_bug.cgi?id=1075164
Verify it as follows.The result is expected. Move its stauts to VERIFIED.
# rpm -q libvirt-python
libvirt-python-1.2.15-1.el7.x86_64
# python
Python 2.7.5 (default, Feb 11 2014, 07:46:25)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> conn = libvirt.open(None)
>>> print "0x%x" % conn.c_pointer()
0x243cc10
>>> dom = conn.lookupByName("r7a")
>>> print "0x%x" % dom.c_pointer()
0x23ff900
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-2203.html