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

[Daniel P. Berrange]

On Tue, Sep 27, 2011 at 12:21:05PM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 27, 2011 at 10:34:19AM +0100, Richard W.M. Jones wrote:
> > (3) libvirtd runs the libguestfs appliance.  It forwards the socket
> > back to us over the libvirt connection.  I think this is what Dan had
> > in mind, and it's reasonably easy to integrate this into both libvirtd
> > and libguestfs.
> 
> [To explain this option in more detail]
> 
> (a) Modify guestfs_add_domain in the case where the libvirt connection
> is remote.  How do we know if the libvirt connection is remote?
> 
>   https://www.redhat.com/archives/libvir-list/2011-April/msg00890.html
> 
> As Dan pointed out elsewhere, any libvirt URI that has a host element
> is probably "remote" even if the host element is "localhost" (since
> that might indicate some sort of cross-user/-policy access).
> 
> (b) Add a libvirt API to open up a remote libguestfs.  Something like
> this:
> 
>   int virConnectStartGuestfsDaemon (
>            virConnectPtr conn,       /* libvirt connection */
>            const char *unix_path,    /* path to local unix domain socket */
>            unsigned int flags
>   );

This is fairly similar to what I just proposed, but I suggested just directly
returning a guestfs_h handle, so that we do't have to hardcode use of a UNIX
domain socket.

> (c) At the remote end, libvirtd launches the libguestfs appliance in qemu.
> 
>   - How would it do this?
>   - Would it reuse libguestfs code for this?

We would want to ultimately call into virDomainCreate() so that we ensure
integration with SELinux/lock manager/disk secrets, etc. So I wouldn't
want to use the libguestfs code for spawning QEMU.

>   - Would it call febootstrap-supermin-helper itself?  Or another method?

Yeah, I imagine we would call that before launching the guest to get out
kernel/initrd/whatever else it outputs.

>   - Do we need to pass any libguestfs parameters over (eg. path? qemu?
>     verbose? append? memsize? selinux?)

Ideally all those could be determined by libvirtd, but perhaps a couple
of them would be exposed as flags.

>   - Where do qemu log messages go to?

/var/log/libvirt/qemu/$GUEST.log

which reminds me that we need to add an API

  virDomainOpenLog(virDomainPtr, virStreamPtr)

to let an mgmt app remotely read the QEMU log.

> (d) The virtio serial port is forwarded back to the libvirt client
> side, causing the Unix domain socket to be opened.
> 
> (e) The libguestfs library now calls guestfs_set_attach_method with
> the name of the socket.

In my proposal those would all be done by the virConnectStartGuestfsDaemon
API....

> 
> (f) The libguestfs tool works away as before.  (No change to the tool
> or API, which is good).

...but this would require changes to any existing apps to use the new
API.

> 
> (g) guestfs_close closes the socket.
> 
>   - Does libvirt detect this automatically?
>   - Do we need to take some action to knock down the forwarding?

With transient guests, you can now set a flag to put them into what we
call an 'auto destroy' mode. This means when the last reference to the
virConnectPtr is released, libvirt will kill the guest. 

If guestfs wanted to start multiple appliances with the same virConnecPtr
then this would not be sufficient and some other form of cleanup would
be needed.


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