Re: [Qemu-devel] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested

["Daniel P. Berrange" <berrange@redhat.com>]

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 <berrange@redhat.com>
> 
> 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 :|