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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list