On 6/18/19 6:43 AM, Vladimir Sementsov-Ogievskiy wrote: > Reconnect will be implemented in the following commit, so for now, > in semantics below, disconnect itself is a "serious error". > > Signed-off-by: Vladimir Sementsov-Ogievskiy > Reviewed-by: Eric Blake > --- > qapi/block-core.json | 11 ++++++++++- > block/nbd.c | 16 +++++++++++++++- > 2 files changed, 25 insertions(+), 2 deletions(-) > > diff --git a/qapi/block-core.json b/qapi/block-core.json > index 61124431d8..17faf723e0 100644 > --- a/qapi/block-core.json > +++ b/qapi/block-core.json > @@ -3858,13 +3858,22 @@ > # traditional "base:allocation" block status (see > # NBD_OPT_LIST_META_CONTEXT in the NBD protocol) (since 3.0) > # > +# @reconnect-delay: On an unexpected disconnect, the nbd client tries to > +# connect again until succeeding or encountering a serious > +# error. During the first @reconnect-delay seconds, all > +# requests are paused and will be rerun on a successful > +# reconnect. After that time, any delayed requests and all > +# future requests before a successful reconnect will > +# immediately fail. Default 0 (Since 4.1) 4.2 now; sorry for the delays. I can make that change; I'll definitely stage at least through this patch for my first pull request as soon as 4.2 opens next week; while still looking at the rest of the series to see if it is ready to go as well. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org