On Thu, Apr 02, 2020 at 08:41:31AM -0500, Eric Blake wrote:
> On 4/2/20 3:38 AM, Richard W.M. Jones wrote:
> >For the case I care about (long running virt-v2v conversions with an
> >intermittent network) we don't expect that nbdkit will be killed nor
> >gracefully shut down. Instead what we
On 4/2/20 8:33 AM, Eric Blake wrote:
Then, what about "SHOULD wait until no inflight requests"? We don't do
it either.. Should we?
qemu as server doesn't send NBD_ESHUTDOWN. It probably should (the way
nbdkit does), but that's orthogonal to qemu as client responding to
NBD_ESHUTDOWN.
On 4/2/20 3:38 AM, Richard W.M. Jones wrote:
On Wed, Apr 01, 2020 at 05:38:41PM -0500, Eric Blake wrote:
I was trying to test qemu's reconnect-delay parameter by using nbdkit
as a server that I could easily make disappear and resume. A bit of
experimenting shows that when nbdkit is abruptly
On 4/2/20 1:41 AM, Vladimir Sementsov-Ogievskiy wrote:
02.04.2020 1:38, Eric Blake wrote:
I was trying to test qemu's reconnect-delay parameter by using nbdkit
as a server that I could easily make disappear and resume. A bit of
experimenting shows that when nbdkit is abruptly killed (SIGKILL),
On Wed, Apr 01, 2020 at 05:38:41PM -0500, Eric Blake wrote:
> I was trying to test qemu's reconnect-delay parameter by using nbdkit
> as a server that I could easily make disappear and resume. A bit of
> experimenting shows that when nbdkit is abruptly killed (SIGKILL),
> qemu detects EOF on
02.04.2020 1:38, Eric Blake wrote:
I was trying to test qemu's reconnect-delay parameter by using nbdkit
as a server that I could easily make disappear and resume. A bit of
experimenting shows that when nbdkit is abruptly killed (SIGKILL),
qemu detects EOF on the socket and manages to reconnect
I was trying to test qemu's reconnect-delay parameter by using nbdkit
as a server that I could easily make disappear and resume. A bit of
experimenting shows that when nbdkit is abruptly killed (SIGKILL),
qemu detects EOF on the socket and manages to reconnect just fine; but
when nbdkit is
