[libvirt] libguestfs integration: rich disk access for libvirt applications
Daniel P. Berrange
berrange at redhat.com
Tue Sep 27 11:38:18 UTC 2011
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
Yeah, I think libvirt will just have to be able to run the
febootstrap-supermin-helper program itself at the appropriate
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, which would be transparent to callers.
|: 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 :|
More information about the libvir-list