[Qemu-devel] nbd oldstyle negotiation

[Qemu-devel] nbd oldstyle negotiation

[Vladimir Sementsov-Ogievskiy]

Hi Eric!

There is a small problem with our qemu-nbd cmdline interface: people 
forget to use option -x or don't know about it and face into problems 
with old protocol version. One of may colleagues after such situation 
(because of this option, he could not use utility nbd-client, which 
doesn't support old version) asked me to add comments about version 
selection by -x option into --help of qemu-nbd. And really, it's not an 
obvious interface solution...

Now I think, should not we use new version by default? Or, even drop old 
version support at all? Anybody uses it?

from nbd spec:
  ... the old style negotiation is now no longer developed; starting 
with version 3.10 of the reference implementation, it is also no longer 
supported.

it's unsupported, I think it's ok to drop it. I can create patches, if 
you agree.

-- 
Best regards,
Vladimir

Re: [Qemu-devel] nbd oldstyle negotiation

[Eric Blake]

On 08/16/2018 02:02 PM, Vladimir Sementsov-Ogievskiy wrote:
> Hi Eric!
> 
> There is a small problem with our qemu-nbd cmdline interface: people 
> forget to use option -x or don't know about it and face into problems 
> with old protocol version. One of may colleagues after such situation 
> (because of this option, he could not use utility nbd-client, which 
> doesn't support old version) asked me to add comments about version 
> selection by -x option into --help of qemu-nbd. And really, it's not an 
> obvious interface solution...
> 
> Now I think, should not we use new version by default? Or, even drop old 
> version support at all? Anybody uses it?

nbdkit 1.3 switched its default to newstyle (Jan 2018):
https://github.com/libguestfs/nbdkit/commit/b2a8aecc
https://github.com/libguestfs/nbdkit/commit/8158e773

and you are correct that nbd 3.10 dropped oldstyle long ago (Mar 2015):
https://github.com/NetworkBlockDevice/nbd/commit/36940193

oldstyle is severely lacking in features (it can't do TLS or efficient 
sparse file handling, for example).  Do we need a formal qemu 
deprecation period (where you still get oldstyle if -x was not used, but 
a nice big warning) before flipping the default in 3.2/3.3 [1], or are 
we okay flipping it in 3.1?

[1] Okay, I know that our new equally-arbitrary policy on when to bump 
qemu version number components means that we'll probably see 3.1 in 2018 
then 4.0 in 2019, rather than 3.2.

And, if we switch the default now (which I am in favor of), do we want 
to add a -o switch to still make it possible to select oldstyle for a 
couple more releases in case someone was relying on it?  Then again, if 
you have to amend your script to use -o to keep things from breaking, 
why not just amend your setup to use newstyle?

My personal preference: completely drop oldstyle support from qemu, for 
3.1, with no deprecation period. Do so by making '-x ""' the default for 
any qemu-nbd command line that did not otherwise specify an export name. 
  If someone still needs interoperability, they can use nbdkit in the 
middle, which will still support oldstyle, and provides a plugin for 
connecting:

newstyle client => nbdkit nbd plugin => oldstyle server
oldstyle client => nbdkit nbd plugin => newstyle server

(well, that plugin could be enhanced to support IP addresses, rather 
than just Unix sockets, but that's a topic for another mailing list)

But I'm open to counter opinions on whether we need to be more 
conservative, and will not rip things out without at least getting 
opinions from others on how aggressive or conservative the switchover 
should be.

> 
> from nbd spec:
>   ... the old style negotiation is now no longer developed; starting 
> with version 3.10 of the reference implementation, it is also no longer 
> supported.
> 
> it's unsupported, I think it's ok to drop it. I can create patches, if 
> you agree.

If you want to create patches, that's also fine by me.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: [Qemu-devel] nbd oldstyle negotiation

[Daniel P. Berrangé]

On Thu, Aug 16, 2018 at 02:56:10PM -0500, Eric Blake wrote:
> On 08/16/2018 02:02 PM, Vladimir Sementsov-Ogievskiy wrote:
> > Hi Eric!
> > 
> > There is a small problem with our qemu-nbd cmdline interface: people
> > forget to use option -x or don't know about it and face into problems
> > with old protocol version. One of may colleagues after such situation
> > (because of this option, he could not use utility nbd-client, which
> > doesn't support old version) asked me to add comments about version
> > selection by -x option into --help of qemu-nbd. And really, it's not an
> > obvious interface solution...
> > 
> > Now I think, should not we use new version by default? Or, even drop old
> > version support at all? Anybody uses it?
> 
> nbdkit 1.3 switched its default to newstyle (Jan 2018):
> https://github.com/libguestfs/nbdkit/commit/b2a8aecc
> https://github.com/libguestfs/nbdkit/commit/8158e773
> 
> and you are correct that nbd 3.10 dropped oldstyle long ago (Mar 2015):
> https://github.com/NetworkBlockDevice/nbd/commit/36940193
> 
> oldstyle is severely lacking in features (it can't do TLS or efficient
> sparse file handling, for example).  Do we need a formal qemu deprecation
> period (where you still get oldstyle if -x was not used, but a nice big
> warning) before flipping the default in 3.2/3.3 [1], or are we okay flipping
> it in 3.1?
> 
> [1] Okay, I know that our new equally-arbitrary policy on when to bump qemu
> version number components means that we'll probably see 3.1 in 2018 then 4.0
> in 2019, rather than 3.2.
> 
> And, if we switch the default now (which I am in favor of), do we want to
> add a -o switch to still make it possible to select oldstyle for a couple
> more releases in case someone was relying on it?  Then again, if you have to
> amend your script to use -o to keep things from breaking, why not just amend
> your setup to use newstyle?
> 
> My personal preference: completely drop oldstyle support from qemu, for 3.1,
> with no deprecation period. Do so by making '-x ""' the default for any
> qemu-nbd command line that did not otherwise specify an export name.  If
> someone still needs interoperability, they can use nbdkit in the middle,
> which will still support oldstyle, and provides a plugin for connecting:

So the key question is if the server switches to newstyle with "" export
name, what versions of qemu client will cease to work. Originally the QEMU
client would refuse to use new style protocol if not export name was given.

I fixed that in

commit 69b49502d8b7b582af79fac5bef7b7ccc2dc9c1e
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Wed Feb 10 18:41:10 2016 +0000

    nbd: use "" as a default export name if none provided
    

So if we mandate new style in the server then we break compat with any
QEMU client that is < 2.6.0

I think that is acceptable as this point in time, as that'll be about
3 years old by time 3.1 comes out.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] nbd oldstyle negotiation

[Richard W.M. Jones]

Just following up on this old thread for documentation purposes:

Was it finally decided to drop oldstyle from qemu client in 3.1?  Was
anything posted to make that happen?  I don't see any patches on the list.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v