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

Re: [Nbd] [RFC] NBD protocol improvement



[this got flagged as spam by sf.net because it lived on my laptop for a few
days rather than getting sent out -- resending...]

On Thu, Sep 11, 2008 at 09:17:54PM +0200, Laurent Vivier wrote:
> Le jeudi 11 septembre 2008 à 12:19 -0400, Paul Clements a écrit :
> > Laurent Vivier wrote:
> > > I use the NBD protocol to connect a virtual machine to a disk image.
> > > 
> > > I'd like to allow the client to specify the file to use.
> > > 
> > > Here is what I propose, all your comments are welcome:

I've actually been considering something very similar to what you're
proposing.

Long-term, my plan is to get rid of the 'one-export-per-port' concept,
and introduce a 'name' concept, where nbd-client is called with the
server hostname and the name, rather than the port; the server would
then use the name to find the right export.

Once that'd be implemented, I was going to apply for an IANA standard
port number -- but we're not even remotely there yet.

> > > * NBD server side:
> > > 
> > >   - put all the disk images in a directory, for instance:
> > > 
> > >     # ls /ISO
> > >     ubuntu-6.06-desktop-amd64.iso
> > >     ubuntu-7.10-desktop-amd64.iso
> > >     ubuntu-8.04-desktop-i386.iso
> > > 
> > >   - run the NBD server with a new parameter to specify the directory
> > >     instead of the filename
> > > 
> > >     # nbd-server 1024 --read-only --directory /ISO

I'm currently considering the command-line interface of NBD to be
deprecated; instead, I'd prefer it if you would add a new config file
parameter.

Also, it might be interesting to add a 'default' option, so that clients
that don't understand the new thing would at least get something.

That would require some changes to your proposal below, though:

> > > * NBD client side
> > > 
> > >   nbd-client isoserver 1024 /dev/nbd0 ubuntu-8.04-desktop-i386.iso
> > > 
> > > * protocol changes:
> > > 
> > > - when used with "--directory", nbd-server sends a disk size of 0 in the
> > > negotiate operation.

This should then be the size of the default option instead (or 0 if
there is no default).

The 'flags' field in the negotiation should get another flag, signalling
that there are alternate exports. If the client replies with a flag of
its own, signalling that it knows about those, then it should send a
filename, as below.

> > > - when nbd-client receive a disk size of zero, it sends a filename
> > > (first bytes is the size of the filename, following bytes are the
> > > filename).

One byte should be enough for length. If you want to be really
future-proof, give it two bytes; but if people want to make a filename
that's longer than 255 bytes (_without_ path component), they're stupid
;-)

> > > - nbd-server receives the filename, opens the file (to avoid security
> > > issues, we use "basename(filename)"), and re-sends a negotiate packet
> > > with the good size.

No need to do the entire negotiation over again -- just the new size
should be enough.

> > > - next is as ususal.
> > 
> > Hi Laurent,
> > 
> > so do you have a patch? Is this a patch to standard nbd-client/server? 
> 
> I have a patch for qemu-nbd.
> 
> But if you agree with the concept, I think I can do a patch for
> nbd-client/server (if I want this becomes an official NBD feature I
> think I have to do it... ;-) )

Indeed :-)

> > Are their any kernel components (I assume not)?
> 
> I didn't dig in, but I don't think so.

Doesn't sound like it to me. Once the export is set up, the protocol
would be exactly the same thing.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

----- End forwarded message -----

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22



Reply to: