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

[Daniel P. Berrange]

On Tue, Sep 27, 2011 at 12:35:21PM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 27, 2011 at 12:20:31PM +0100, Daniel P. Berrange wrote:
> > One other point worth mentioning is that libguestfs.so does not want
> > to directly link to libvirt.so, and vica-verca, to ensure we both
> > avoid pulling major new dependancy chains for all users.
> 
> Actually libguestfs.so in Fedora links to libvirt.so today.  What we
> don't want is libvirt to be required *for libguestfs to compile*.
> 
> At the moment if libvirt is not available, we disable one API at
> compile time (using #ifdef HAVE_LIBVIRT etc).  I don't this discussion
> is affected by this.
> 
> > If I were ignoring the requirement that libguestfs does not link to
> > libvirt, then you could quite likely make all this happen with only
> > a simple additional API in libvirt. We need an API to let a client
> > open a connection to a <channel> device, using the virStreamPtr
> > API.
> > 
> > If the guests were not running, libguestfs would use virDomainCreate
> > to spawn a transient, auto-detroy guest, with a custom kernel/initrd
> > that runs the appliance, and an additional <channel> device, but with
> > all other parts of the guest XML unchanged. This would ensure all the
> > lock manager, sVirt and secret stuff 'just works'. If the guest is
> > already running, libguestfs would just query the XML to find the
> > <channel> device configuration. Then it could just use a new API
> > like virDomainOpenChannel(virStreamPtr, const char *channelid) to
> > get a stream to talk to the guestfs daemon with.
> 
> I'm with you up to here, but there's a practical problem: How do we
> create the appliance kernel/initrd/root disk on the server side?  (I'm
> assuming that libvirt doesn't forward these large objects from the
> client to the server.)  Normally these objects are created by running
> febootstrap-supermin-helper.

Yeah, I think libvirt will just have to be able to run the
febootstrap-supermin-helper program itself at the appropriate
time.

As long as we create some SELinux security policy to confine
the febootstrap-supermin-helper I don't see that as a very
significant problem. I think the SELinux policy would be quite
straightforward to create, since the program has a pretty well
defined single task to perform

> > To do this I would create what I call a bridging library, to be
> > named 'libvirt-guestfs.so'.
> 
> See above, although we have converged on similar designs, but for
> different reasons.
> 
> FWIW as outlined in the other email, I think we can do this without a
> bridging library, and just making changes behind the scenes in
> guestfs_add_domain[1], which would be transparent to callers.
> 


Daniel
-- 
|: 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 :|