6:57 a.m.
On 3/23/19 6:42 AM, Richard W.M. Jones wrote:
nbdkit (upstream 5a7a394c699) currently fails with qemu 2.12.0:
$ ./nbdkit memory size=64M --run 'qemu-img convert $nbd /var/tmp/out'
nbdkit: memory.2: error: invalid request: unknown command (7) ignored
qemu-img: Protocol error: simple reply when structured reply chunk was expected
This was a bug in qemu which was fixed upstream quite a long time ago
by the commit I've attached at the end of this email.
Unfortunately RHEL 7.6 & 7.7 (qemu-kvm-rhev-2.12.0-25.el7) doesn't
contain the fix. I wonder if we should:
(a) Not worry about it - it's Red Hat's problem.
Upstream qemu has moved on, so from that perspective, yes, it's Red
Hat's problem (Red Hat must ensure that any versions of qemu and nbdkit
that it ships and which must interoperate do so correctly, whether that
be qemu from RHEL 7 and nbdkit from RHEL 8, or the other way around).
(b) Try and get it fixed in RHEL. I filed a BZ already but I guess it
won't be fixed any time soon: https://bugzilla.redhat.com/1692018
Several RHEL 7 bugs against NBD are pending - there's hope for RHEL 7.7,
but you are also right that guessing timelines is hard.
(c) Add a workaround in nbdkit.
And what workaround would that be? Looking at the qemu patch, the
problem is that qemu asked for "base:allocation" and nbdkit replied with
0 contexts. The workaround would either be to reply with
NBD_REP_ERR_UNSUP (the behavior before NBD_OPT_SET_META_CONTEXT was
added), or to implement "base:allocation" (even if we implement the
poor-man's version that always reports that the entire image is data,
for all requests, without any feedback from the plugins). The former
feels odd, but the latter seems oddly appealing as progress towards our
end goal (kind of how our initial implementation of NBD_CMD_WRITE_ZEROES
was always advertised even before we finished wiring up plug support).
I feel that we probably shouldn't be broken out of the box with
RHEL
and CentOS 7.6 and 7.7, even though it's not an nbdkit (or qemu) bug.
Correct that it is not nbdkit's bug; it was a bug in qemu (but one that
upstream no longer worries about), and old enough of a qemu release that
I don't the the NBD protocol needs to bother mentioning it as a special
case.
Rich.
----------------------------------------------------------------------
89aa0d87634e2cb98517509dc8bdb876f26ecf8b is the first bad commit
commit 89aa0d87634e2cb98517509dc8bdb876f26ecf8b
Author: Vladimir Sementsov-Ogievskiy <vsementsov(a)virtuozzo.com>
Date: Fri Apr 27 17:20:01 2018 +0300
nbd/client: fix nbd_negotiate_simple_meta_context
Initialize received variable. Otherwise, is is possible for server to
answer without any contexts, but we will set context_id to something
random (received_id is not initialized too) and return 1, which is
wrong.
To solve it, just initialize received to false. Initialize received_id
too, just to make all possible checkers happy.
Bug was introduced in 78a33ab58782efdb206de14 "nbd: BLOCK_STATUS for
standard get_block_status function: client part" with the whole
function.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov(a)virtuozzo.com>
Message-Id: <20180427142002.21930-2-vsementsov(a)virtuozzo.com>
Reviewed-by: Eric Blake <eblake(a)redhat.com>
CC: qemu-stable(a)nongnu.org
Signed-off-by: Eric Blake <eblake(a)redhat.com>
:040000 040000 9993feb118af1a9a59dbc8fe92015a324e93e557
14db90d621d6b7f1ee5ff97a0ca2cb92f6f2f7e9 M nbd
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org