From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZOq-0002Tj-P4 for qemu-devel@nongnu.org; Tue, 19 Jan 2016 11:44:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLZOp-0003pg-IH for qemu-devel@nongnu.org; Tue, 19 Jan 2016 11:44:56 -0500 Date: Tue, 19 Jan 2016 16:44:43 +0000 From: "Daniel P. Berrange" Message-ID: <20160119164443.GP26662@redhat.com> References: <1453208963-16834-1-git-send-email-berrange@redhat.com> <1453208963-16834-10-git-send-email-berrange@redhat.com> <569E60E8.2040001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <569E60E8.2040001@redhat.com> Subject: Re: [Qemu-devel] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org On Tue, Jan 19, 2016 at 05:14:32PM +0100, Paolo Bonzini wrote: > > > On 19/01/2016 14:09, Daniel P. Berrange wrote: > > The NBD client is currently only capable of using the new style > > protocol negotiation if an explicit export name is provided. > > This is a problem, because TLS support will require use of the > > new style protocol in all cases, and we wish to keep the export > > name as an optional request for backwards compatibility. > > > > The trivial way to deal with this is to use the NBD protocol > > option for listing exports and then pick the first returned > > export as the one to use. This makes the client "do the right > > thing" in the normal case where the qemu-nbd server only > > exports a single volume. > > > > Furthermore, in order to get proper error reporting of unknown > > options with fixed new style protocol, we must not send the > > NBD_OPT_EXPORT_NAME as the first thing. Thus, even if an export > > name is provided we still send NBD_OPT_LIST to enumerate server > > exports. This also gives us clearer error reporting in the case > > that the requested export name does not exist. If NBD_OPT_LIST > > is not supported, we still fallback to using the specified > > export name, so as not to break compatibility with old QEMU > > NBD server impls that predated NBD_OPT_LIST > > > > Signed-off-by: Daniel P. Berrange > > As a first reaction, I would really avoid magic unless the server > provides a single exports. But even in that case, I would prefer to > have some synchronization between the server and client command-line. > > Is an empty NBD_OPT_EXPORT_NAME valid? What about using new-style > negotiation with empty NBD_OPT_EXPORT_NAME if TLS is requested? The main goal here is to ensure the NBD client gets a decent error message if it tries to connect without TLS. Even if we are using the fixed new style protocol, the client code will send NBD_OPT_EXPORT_NAME as the first thing it does. Thanks to a bit of crazyness is the NBD protocol spec, the server is unable to reply with an error message to NBD_OPT_EXPORT_NAME. So if the client connected to a server reqiuring TLS and does not request TLS enablement, the server will have no choice but to just close the connection with no error. I think this will be pretty nasty for users trying to debug problems with TLS. The NBD_OPT_LIST option is the only option available which we can unconditionally invoke from the client which will get us a clear response from the server that TLS is required. So AFAICT we have no choice but to use that if we want decent error reporting. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|