[libvirt] [RFC] Image Fleecing for Libvirt (BZ 955734, 905125)

[Daniel P. Berrange]

On Wed, Jul 24, 2013 at 11:12:01AM +0100, Richard W.M. Jones wrote:
> On Wed, Jul 24, 2013 at 10:51:35AM +0100, Daniel P. Berrange wrote:
> > I'm wondering if we could instead try to utilize the virStreamPtr
> > APIs for this task. From a libvirt's RPC POV this much more efficient
> > because once you open the region with a stream API, you don't have any
> > round trips at all - the data is pushed out to/from the client async.
> > 
> > Now those APIs are currently designed for sequential streaming of
> > entire data regions only, but I wonder if we could extend them
> > somehow to enable seek'ing within the stream. Alternatively perhaps
> > we could just say if you want to read from dis-joint regions, that
> > you can just re-open a stream for each region to be processed.
> 
> It'd be so much easier from a client point of view if you just exposed
> the NBD Unix socket directly.  libvirt already exposes qemu sockets
> directly (eg. console, virtio-serial sockets).  It should forward
> those sockets from the remote side transparently too.

That's a possibility, though it pretty much rules out implementing
this functionality for other hypervisors, unless they add a dep on
qemu-nbd or another NBD server. eg we could potentially design an
API that works fine with VMWare ESX, but if we expose NBD as the
"api", then our VMWare driver is doomed, since I don't expect
VMWare to ever implement NBD.

A question around direct exposure of NBD would be that of authentication
and data security of the NBD server. QEMU's NBD server has no auth
and if you're accessing it over TCP from a remote host you have no
data encryption either. A libvirt stream API could address both of
those issues.

That all said I'm not neccessarily against just exposing NBD directly.
For local use, we could also have a FD passing based API where the
livirt API call returns a pre-opened FD connected to the NBD server,
and simply warn people that exposing NBD over TCP requires a trusted
network.

Another option would be to actually tunnel the NBD protocol over the
pre-authenticated & secured libvirt RPC protocol. This isn't much
different to using the virStreamPr APIs, but perhaps would be easier
than trying to add random-access to the stream APIs & be easier for
a existing NBD client to integrate with.

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