From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2gcv-0007cp-DL for qemu-devel@nongnu.org; Tue, 17 May 2016 11:09:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2gcp-0005nR-NM for qemu-devel@nongnu.org; Tue, 17 May 2016 11:09:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44319) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2gcp-0005n6-GA for qemu-devel@nongnu.org; Tue, 17 May 2016 11:09:35 -0400 References: <1455640486-6101-1-git-send-email-pbonzini@redhat.com> <1455640486-6101-24-git-send-email-pbonzini@redhat.com> <20160517095339.GD28935@redhat.com> From: Eric Blake Message-ID: <573B342E.8030208@redhat.com> Date: Tue, 17 May 2016 09:09:34 -0600 MIME-Version: 1.0 In-Reply-To: <20160517095339.GD28935@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h0iKBQi7KS71OQK3jQrpi2PU0fMvDp71T" Subject: Re: [Qemu-devel] [PULL 23/28] nbd: always query export list in fixed new style protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Richard W.M. Jones" , Paolo Bonzini , berrange@redhat.com Cc: qemu-devel@nongnu.org, "nbd-general@lists.sourceforge.net" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h0iKBQi7KS71OQK3jQrpi2PU0fMvDp71T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [adding nbd-list] On 05/17/2016 03:53 AM, Richard W.M. Jones wrote: > On Tue, Feb 16, 2016 at 05:34:41PM +0100, Paolo Bonzini wrote: >> From: "Daniel P. Berrange" >> >> With the new style protocol, the NBD client will currenetly >> send NBD_OPT_EXPORT_NAME as the first (and indeed only) >> option it wants. The problem is that the NBD protocol spec >> does not allow for returning an error message with the >> NBD_OPT_EXPORT_NAME option. So if the server mandates use >> of TLS, the client will simply see an immediate connection >> close after issuing NBD_OPT_EXPORT_NAME which is not user >> friendly. >> > I just bisected qemu 2.6 to find out where it breaks interop with > nbdkit, and it is this commit. >=20 > nbdkit implements the newstyle protocol, but doesn't implement export > names (yet, maybe in future). It processes the NBD_OPT_EXPORT_NAME > option, but ignores the export name and carries on regardless. >=20 > nbdkit's implemention of NBD_OPT_LIST returns an error, because there > is no such thing as a list of export names supported (in effect nbdkit > allows any export name). Perhaps nbdkit should implement NBD_OPT_LIST returning just "" (the default name) as its only list entry? And at some point, nbdkit should probably implement NBD_OPT_GO (which is a nicer replacement to NBD_OPT_EXPORT_NAME; I've got patches pending for qemu to implement that). In fact, if NBD_OPT_GO is supported, then my patches to qemu won't even try NBD_OPT_LIST. >=20 > Therefore I don't believe the assumption made here -- that you can > list export names and choose them on the client side -- is a valid > one. Qemu is not choosing an export name, so much as proving whether any OTHER errors can be detected (such as export name not present, or TLS required). It _should_ be gracefully ignoring NBD_OPT_LIST errors if such errors don't definitively prove that the export will not succeed, but I guess this is not happening. I'll see if I can tweak the qemu logic to be more forgiving of nbdkit's current behavior. >=20 > Naturally the protocol document > (https://github.com/yoe/nbd/blob/master/doc/proto.md) isn't clear on > this case. You're right that we may also want to tweak the NBD protocol to make this interoperability point obvious. >=20 > To test qemu against nbdkit you can do this in the nbdkit sources: >=20 > make > make check TESTS=3Dtest-newstyle \ > LIBGUESTFS_HV=3D/path/to/qemu/x86_64-softmmu/qemu-system-x86_64 \ > LIBGUESTFS_DEBUG=3D1 LIBGUESTFS_TRACE=3D1 >=20 > Rich. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --h0iKBQi7KS71OQK3jQrpi2PU0fMvDp71T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXOzQuAAoJEKeha0olJ0NqNfMH/j1lC0kC6FYStCSmRqtcGw06 gcQXVxW/wysVfm6vWMrrFORUO8S6yB3441DLnvf3baUlSvOvolqWEl6tmgn1l5Xm /FMlIuo9jJj23cZJvZMH66/2p/+/SwoWhNjhXnjKO6XPI0YYIm17G7zRbwkEvcAg g06bbhNXmQ6orYcY6VeF0P/3UkTFvLTrZERpjSPRONHxh4wJcnQ1oUNgx+y80EVF t29pk9++rZLxklL6SnvkvCIcep0dK6JFeT1T72ub1JsObQjsYWbp0/0PDbKOkIrB OY9qsQWgIlhVFmrjB54dTVZbV8VFn8otu8aqxOwSPTPHKmzJlbtOJRXePCQvmZs= =n1+S -----END PGP SIGNATURE----- --h0iKBQi7KS71OQK3jQrpi2PU0fMvDp71T--