Libguestfs - May 2023 - [PATCH v3 12/14] nbd/client: Request extended headers during negotiation

On 31.05.23 20:54, Eric Blake wrote:
> On Wed, May 31, 2023 at 08:39:53PM +0300, Vladimir Sementsov-Ogievskiy
wrote:
>> On 15.05.23 22:53, Eric Blake wrote:
>>> All the pieces are in place for a client to finally request
extended
>>> headers.  Note that we must not request extended headers when
qemu-nbd
>>
>> why must not? It should gracefully report ENOTSUP? Or not?
> 
> The kernel code does not yet know how to send extended requests; once
> extended mode is negotiated, sending a simple request requires the
but how it could be negotiated if kernel doesn't support it?

I mean if we request extended headers during negotiation with kernel, the kernel
will just say "unsupported option", isn't it?

Or, in other words, I understand that kernel doesn't support it, I don't
understand why you note it here. Is kernel different from other NBD server
implementations which doesn't support extended requests at the moment?


-- 
Best regards,
Vladimir

On Wed, May 31, 2023 at 09:33:20PM +0300, Vladimir Sementsov-Ogievskiy
wrote:
> On 31.05.23 20:54, Eric Blake wrote:
> > On Wed, May 31, 2023 at 08:39:53PM +0300, Vladimir Sementsov-Ogievskiy
wrote:
> > > On 15.05.23 22:53, Eric Blake wrote:
> > > > All the pieces are in place for a client to finally request
extended
> > > > headers.  Note that we must not request extended headers
when qemu-nbd
> > > 
> > > why must not? It should gracefully report ENOTSUP? Or not?
> > 
> > The kernel code does not yet know how to send extended requests; once
> > extended mode is negotiated, sending a simple request requires the
> 
> but how it could be negotiated if kernel doesn't support it?
That's the problem.  The kernel doesn't do the negotiation, userspace
does.  There is an ioctl for the userspace to tell the kernel what
flags were advertised as part of the negotiation, but that does not
include a flag for extended operation.  The kernel ONLY takes care of
NBD_CMD_ operations, it does not do NBD_OPT_ operations.  So when
qemu-nbd is preparing to connect to /dev/nbdN, it first has to
negotiate in userspace, avoiding any attempt to use extended headers,
then call the right ioctls for the kernel to take over command phase
using the older compact headers.
> 
> I mean if we request extended headers during negotiation with kernel, the
kernel will just say "unsupported option", isn't it?
If we request extended headers in userspace before calling the ioctl
to tell the kernel to start transmission, then the kernel's first
command will use the compact style, which the server is not expecting,
and while we can hope the server will hang up on the kernel, I didn't
test what actually happens.

> 
> Or, in other words, I understand that kernel doesn't support it, I
don't understand why you note it here. Is kernel different from other NBD
server implementations which doesn't support extended requests at the
moment?
The kernel is an NBD client, not a server.  But if we are about to
connect an NBD server over to the kernel for /dev/nbdN, we better make
sure the server is not using any features the kernel doesn't support.

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