On 02/11/2017 13:02, Daniel P. Berrange wrote: > > After all that long background explanation, what I'm wondering is whether > there is any interest / desire to extend qemu-nbd to have more advanced > featureset than simply exporting a single disk image which must be listed > at startup time. > > - Ability to start qemu-nbd up with no initial disk image connected > - Option to have a QMP interface to control qemu-nbd > - Commands to add / remove individual disk image exports > - Commands for doing the drive-mirror / backing file pivot > > It feels like this wouldn't require significant new functionality in either > QMP or block layer. It ought to be mostly a cache of taking existing QMP > code and wiring it up in qemu-nbd, and only exposing a whitelisted subset > of existing QMP commands related to block backends.
I think adding a QMP interface is a good idea; if you're using Unix sockets I don't see much benefit in using multiple disk image exports from a single qemu-nbd instance, but maybe you aren't? At this point it does indeed feel a lot like --machine none. Perhaps we should just have a new binary /usr/bin/qemu-noguest instead of augmenting qemu-nbd. Would you also add rerror/werror support to qemu-nbd at the same time? Paolo
