Paolo Bonzini <pbonz...@redhat.com> writes: >> Why's nbd_server_add not needed in HMP? >> >> Oh, it's because HMP's nbd_server_start auto-adds *all* block >> devices, unlinke QMP's nbd-server-start. >> >> Are you sure that's a good idea? > > Yes. Now that we have QMP we can go back and treat HMP as (mostly) a > debugging interface as it was meant to be. > > You don't need any fine-grained control in that case. From the server's > point of view, serving all devices or just one is exactly the same thing. > If you use NBD for block migration, for example, you can choose _on the > source_ which devices you are migrating, but it doesn't harm if more > devices are exposed on the target. > > The only case where this loses is when you hotplug a device and you want > to start serving it. I think this is a minor loss for HMP, but it is a > show-stopper for QMP which hence has to have nbd-server-add.
Apropos hotplug. The only way to unexport a block device is to stop the NBD server outright. Once the device backend has been exported, unplugging the device gets rid of the frontend, but the backend stays until you stop the NBD server, or you kill the backend with the big drive_del hammer. Makes me wonder whether we need QMP command nbd-server-del. Back to HMP. I agree that we can the human monitor is again for human users only, thus we don't have to encumber it with the need of tools. I might also buy your argument that extra exports don't really hurt. But device plug / -unplug is just as relevant there as in QMP. If it's a show-stopper for QMP, then I don't think it can be a "minor loss" for HMP. Additionally, two details I don't like: 1. The HMP command looks just like the QMP command (name & arguments), yet does something else. 2. What if we ever change our minds regarding fine-grained NBD export control in the human monitor? Add a second command to start the server without exporting everything? Add a "don't auto-export" argument to the existing command?
