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

[Richard W.M. Jones]

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.

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

Rich.

[1] http://git.annexia.org/?p=libguestfs.git;a=blob;f=src/virt.c;hb=HEAD

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw