[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
Daniel P. Berrange
Re: [Qemu-block] [PATCH v3 09/13] nbd: pick first exported volume if no export name is requested
Tue, 19 Jan 2016 16:44:43 +0000
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 <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?
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.
|: 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 :|
[Qemu-block] [PATCH v3 11/13] nbd: enable use of TLS with NBD block driver, Daniel P. Berrange, 2016/01/19
[Qemu-block] [PATCH v3 13/13] nbd: enable use of TLS with nbd-server-start command, Daniel P. Berrange, 2016/01/19
[Qemu-block] [PATCH v3 12/13] nbd: enable use of TLS with qemu-nbd server, Daniel P. Berrange, 2016/01/19