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

Reply via email to