qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v3 09/13] nbd: pick first exported volume if no


From: Paolo Bonzini
Subject: Re: [Qemu-block] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested
Date: Tue, 19 Jan 2016 17:14:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0


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 <address@hidden>

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

[Prev in Thread] Current Thread [Next in Thread]