On Thu, Apr 12, 2018 at 09:22:16AM +0000, Nir Soffer wrote:
> I think we can expose NBD using ndb-server and dynamic exports.
> It can work like this:
> 0. Install nbd and enable nbd-server on a host, running
>    as vdsm:kvm, not exporting anything.
> 1. User starts transfer session via oVirt API with protocol="nbd"
>     (if not specified, use "https" for backward compatibility)
> 2. oVirt selects a host for the transfer and configures an export
>    in that host - for example:
> [bbff5ab7-2e8e-45b8-a497-423c2d2b3ff1]
> exportname = /path/to/image
> trim = yes
> timeout = 300
> nbd-server supports reloading configuration via SIGHUP.
> Looks like it should work for adding export dynamically:
> https://github.com/NetworkBlockDevice/nbd/blob/cb6e816c4d2c536cfff5ba9859f210aabe39539b/nbd-server.c#L3007

I don't think we have nbd-server in RHEL, and in any case wouldn't it
be better to use qemu-nbd?

You just start a new qemu-nbd process instead of faffing around with
configuration files, kill the qemu-nbd process when you're done, and
qemu-nbd supports qcow2 already.

It doesn't support progress, but it's not very clear what "progress"
means for an NBD connection, since it's quite reasonable to go back
and rewrite blocks, or (as with qemu-img convert) issue zeroes, or
trims, etc.  It might be better simply to derive progress from ‘du -s
target_file’, ‘qemu-img info target.qcow2’ or similar.


Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.

Reply via email to