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? Paolo