Bug 1075164 - RFE: allow passing in a pre-opened libvirt connection from python
Summary: RFE: allow passing in a pre-opened libvirt connection from python
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1075143 1175795
TreeView+ depends on / blocked
 
Reported: 2014-03-11 15:47 UTC by Cole Robinson
Modified: 2014-12-18 15:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1175795 (view as bug list)
Environment:
Last Closed: 2014-12-12 14:02:59 UTC
Embargoed:


Attachments (Terms of Use)
test.py (1.54 KB, text/plain)
2014-12-11 13:36 UTC, Richard W.M. Jones
no flags Details

Description Cole Robinson 2014-03-11 15:47:20 UTC
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.

Comment 1 Richard W.M. Jones 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.

Comment 2 Richard W.M. Jones 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).

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.

Comment 3 Cole Robinson 2014-05-15 14:10:49 UTC
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.

Comment 4 Richard W.M. Jones 2014-12-10 20:56:27 UTC
(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.

Comment 6 Richard W.M. Jones 2014-12-11 11:32:09 UTC
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

Comment 7 Richard W.M. Jones 2014-12-11 13:36:57 UTC
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.

Comment 8 Richard W.M. Jones 2014-12-11 14:20:10 UTC
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

Comment 10 Richard W.M. Jones 2014-12-12 14:02:59 UTC
libvirt-python change ACKed and pushed upstream, therefore
I am closing this bug.


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