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