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