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.
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.
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). Libvirt could provide a separate C library for converting Python "dom" objects to virDomainPtr. It would have to do this for every binding that libguestfs supports (which is more than libvirt currently has). Or perhaps there is some other way to do this that we haven't found yet.
Every python libvirt object has self._o, which contains a pointer to the raw C object. Using that might 'just work'. Of course, if it does work we should add an official libvirt-python API call to get _o rather than access the private object, but you could use _o to test it out for now.
(In reply to Cole Robinson from comment #3) > Every python libvirt object has self._o, which contains a pointer to the raw > C object. Using that might 'just work'. Of course, if it does work we should > add an official libvirt-python API call to get _o rather than access the > private object, but you could use _o to test it out for now. It also requires this macro which exposes more internals from libvirt-python: #define PyvirDomain_Get(v) (((v) == Py_None) ? NULL : \ (((PyvirDomain_Object *)(v))->obj)) typedef struct { PyObject_HEAD void * /* really virDomainPtr */ obj; } PyvirDomain_Object; Nevertheless I made it work and will post a patch shortly.
https://www.redhat.com/archives/libguestfs/2014-December/thread.html#00092
Had a slighty better idea about how to implement this. First we modify libvirt-python to add a c_pointer() method for all classes: https://www.redhat.com/archives/libvir-list/2014-December/msg00615.html Then we need an updated patch series for libguestfs which uses the c_pointer() method and doesn't require any insight into internal details of libvirt-python: https://www.redhat.com/archives/libguestfs/2014-December/thread.html#00111
Created attachment 967238 [details] test.py I wanted to find out if this approach even fixes the problem we're trying to solve. The answer is no, for the same reason as noted here: https://bugzilla.redhat.com/show_bug.cgi?id=912499#c10 See attached program. It's not clear if it's the job of libguestfs to label the overlay. But I will have a go and see if that makes any difference.
OK, turns out this was a regression in the libguestfs labelling code. The new patch series contains a fix for that too (patch 6/6): https://www.redhat.com/archives/libguestfs/2014-December/thread.html#00118
Upstream in libguestfs: https://github.com/libguestfs/libguestfs/commit/fd9ac7f47d769e8319ec597ae6688d4e2bfa55a6 https://github.com/libguestfs/libguestfs/commit/96158d42f5cb9b6c472b4630f2c97edae600f6d3 https://github.com/libguestfs/libguestfs/commit/db1c8a6436c12b4a7f2e29bd4b926c5b064048b7 https://github.com/libguestfs/libguestfs/commit/2c9f6da03464279db9a2baa24c32e2a9b64f713a https://github.com/libguestfs/libguestfs/commit/f4b4dcc03aa06a4afdb02d81b56806f8a9c6dd78 https://github.com/libguestfs/libguestfs/commit/39f7eaea80c103d9b1cdf1826c4bc70c304c860e https://github.com/libguestfs/libguestfs/commit/90e9ad7ff963571718935ff22f96582515b55763 As this requires a change to libvirt-python: https://www.redhat.com/archives/libvir-list/2014-December/msg00615.html I am going to leave this bug open.
libvirt-python change ACKed and pushed upstream, therefore I am closing this bug.