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 <berra...@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 :|
