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

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.