[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NBD reconnect on open
From: |
Kevin Wolf |
Subject: |
Re: NBD reconnect on open |
Date: |
Wed, 4 Dec 2019 14:22:05 +0100 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
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