[libvirt] libguestfs integration: rich disk access for libvirt applications

Daniel P. Berrange berrange at redhat.com
Tue Sep 27 11:43:20 UTC 2011

On Tue, Sep 27, 2011 at 12:21:05PM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 27, 2011 at 10:34:19AM +0100, Richard W.M. Jones wrote:
> > (3) libvirtd runs the libguestfs appliance.  It forwards the socket
> > back to us over the libvirt connection.  I think this is what Dan had
> > in mind, and it's reasonably easy to integrate this into both libvirtd
> > and libguestfs.
> [To explain this option in more detail]
> (a) Modify guestfs_add_domain in the case where the libvirt connection
> is remote.  How do we know if the libvirt connection is remote?
>   https://www.redhat.com/archives/libvir-list/2011-April/msg00890.html
> As Dan pointed out elsewhere, any libvirt URI that has a host element
> is probably "remote" even if the host element is "localhost" (since
> that might indicate some sort of cross-user/-policy access).
> (b) Add a libvirt API to open up a remote libguestfs.  Something like
> this:
>   int virConnectStartGuestfsDaemon (
>            virConnectPtr conn,       /* libvirt connection */
>            const char *unix_path,    /* path to local unix domain socket */
>            unsigned int flags
>   );
> (c) At the remote end, libvirtd launches the libguestfs appliance in qemu.
>   - How would it do this?
>   - Would it reuse libguestfs code for this?
>   - Would it call febootstrap-supermin-helper itself?  Or another method?
>   - Do we need to pass any libguestfs parameters over (eg. path? qemu?
>     verbose? append? memsize? selinux?)
>   - Where do qemu log messages go to?
> (d) The virtio serial port is forwarded back to the libvirt client
> side, causing the Unix domain socket to be opened.
> (e) The libguestfs library now calls guestfs_set_attach_method with
> the name of the socket.

Since you don't mind using libvirt APIs internally if they #ifdef'able,
then how practical is it to change the I/O routines inside libguestfs
to optionally use virStreamRecv/virStreamSend directly, instead of
having to proxy the stream via a client side UNIX socket ?

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

More information about the libvir-list mailing list