24.04.2018 16:08, Vladimir Sementsov-Ogievskiy wrote:
> Hi all.
>
> Here is a draft of NBD reconnect, to negotiate overall design. It is done
> through implementing new error action: reconnect.
>
> New action works as follows:
>
> Firstly, not stopping the vm, it tries to bdrv_reconnect several times
> with given pause. Then, if we failed to reconnect fallthrough to 'stop'
> error action.
>
> My RFC doubts:
> 1. introducing new .bdrv_reconnect(). Is bdrv_reopen() appropriate for
> the feature? I'm not sure, because it is not recursive, and don't
> really reopen files..
> 2. introducing new error action. Anyway, I'll have to add some configuration
> parameters (see 03), so, the feature may be just an option to 'stop'
> action, rather than separate error action.
>
> Vladimir Sementsov-Ogievskiy (3):
> block: add bdrv_reconnect
> nbd: add .bdrv_reconnect handler
> blk: add 'reconnect' error action
>
> qapi/block-core.json | 4 ++--
> include/block/block.h | 2 ++
> include/block/block_int.h | 3 +++
> block.c | 22 +++++++++++++++++
> block/block-backend.c | 48 ++++++++++++++++++++++++++++++++++++-
> block/nbd.c | 60 ++++++++++++++++++++++++++++++++++-------------
> hw/scsi/scsi-disk.c | 4 +++-
> 7 files changed, 123 insertions(+), 20 deletions(-)
>
Hm, answering myself:
it's a bad design:
1. Assume we have a tree of nodes. So, if one node was disconnected, we
will reconnect all nodes. It's better to reconnect only one node.
2. Possibility to reconnect looks more like option, rather than separate
error_action, as we may want reconnect before stop in _STOP action, and
reconnect if disconnected with _NOSPC error action.
So, I'll try to rewrite it to be a simple nbd-driver option.
--
Best regards,
Vladimir