Am 04.12.2019 um 13:18 hat Vladimir Sementsov-Ogievskiy geschrieben: > There is a question to discuss. > > We need to make an option to allow nbd-reconnect loop on nbd-open. > For example, add optional nbd blockdev option open-reconnect-delay, to > make it possible to start qemu with specified nbd connection, when nbd > server is down, and make several tries to connect before starting the > guest. > > So, we need it for nbd opened from commandline arguments, and this case > seems OK. > > But adding option to QAPI, we also allow it for qmp blockdev-add, and > reconnecting in context of qmp command execution is a wrong thing.. > > I can add new option only to options in block/nbd.c, but this way > -blockdev command line option will not work, it needs QAPI definition. > > What do you think about it?
I think there is a more general problem here actually. bdrv_open() is a blocking operation and it shouldn't be. BlockDriver should probably have a .bdrv_co_open instead, and I think this wouldn't be too hard to do. However, that's only half of the solution: QMP still takes the BQL while it's executing a command, so even if we used a coroutine, it would be of no use if then the QMP command implementation would just call BDRV_POLL_WHILE() to wait for the completion of the coroutine while holding the BQL. This is going in direction of async commands that Marc-André was working on. I didn't follow this closely, so I'm not sure what the status there is, but he and Markus should be able to tell more. > I can detect somehow in nbd_open that we are in qmp monitor context, and > return error if open-reconnect-delay specified.. Is it OK? Is there a > way to do it? The whole point of -blockdev is that it's a direct mapping of blockdev-add to the command line, so making things behave differently between them sounds like a bad idea. Kevin
