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. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list