Bug 1175795

+++ 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).