On 2/28/19 12:18 PM, Daniel P. Berrangé wrote: >> It doesn't hold up this patch, but I note that with the qemu QMP command >> changes you make in 2/3, you document that the object can be >> created/removed on the fly, and the server will adjust which clients can >> then subsequently connect. Is there any need for the same sort of >> runtime configurability in qemu-nbd, and if so, how would we accomplish >> it? Perhaps by having a command-line option to parse --tls-authz from a >> file, where you can send SIGHUP to qemu-nbd to force it to re-read the >> file? Or am I worrying about something unlikely to be needed in practice? > > Well the QAuthZListFile object type can store its contents in an external > file that gets auto-reloaded upon inotify triggers from the main loop. > The QAuthZPAM type can also be fairly dynamic depending on its backend. > I think any single process is unlikely to need to switch between > different object types, so this is good enough dynamic support.
That, and QMP nbd-server-start can serve up multiple exports, while qemu-nbd serves exactly one export. I also note that my work on incremental backups has raised the topic that we someday want to support multiple parallel NBD servers. Right now, you are limited to exactly one (even though it can server multiple exports), which makes serving different content to different clients harder than if you could have different servers on separate ports with per-server settings on which clients to allow. Or, if we have tls-authz items per-export instead of per-server, so that different clients see a different subset of available exports when doing NBD_OPT_LIST. > > I can't help thinking we should add QMP to qemu-nbd one day though.... Yeah, as QMP nbd server gets more powerful, we may eventually need a similar monitor interface into controlling a long-running qemu-nbd process... -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
