On Sun, Feb 13, 2022 at 05:13:37PM +0200, Nir Soffer wrote: > This can be done in nbdcopy by adding http-ops. The pipeline in > rhv-upload case will be: > > nbdkit (any input) -> nbdcopy (nbd-ops/http-ops) -> imageio server > > Another way is to drop nbdcopy for rhv-upload - if we provide nbd > input, we can use imageio client to read from the nbd input and write > to imageio server. The pipeline will be: > > nbdkit (any input) -> imageio client -> imageio server > > This means that the v2v output can optionally do the copy phase, > if it knows how to read from the nbdkit input. > > Yet another way is to rewrite imageio in Go, and use libnbd async API, > which will eliminate most of the overhead of the http requests. I started > this work with the imageio client side. You can check what we have so > far here: > https://github.com/oVirt/ovirt-imageio/tree/master/ovirt-img > > For the long term, I think improving nbdcopy to support additional > input/output backends is the right way and will make it more useful > for other purposes.
This doesn't work for virt-v2v. We want to expose NBD pipelines so that eventually external programs which work across multiple running virt-v2v instances can do the copying. This cannot work if the external programs have to worry about special cases. This is also a reason why I'm lukewarm about special casing nbdcopy parameters, although in this case it's only an optimization. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html _______________________________________________ Libguestfs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/libguestfs
