Re: [Nbd] [RFC] NBD protocol improvement
- To: Wouter Verhelst <w@...112...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] [RFC] NBD protocol improvement
- From: Laurent Vivier <Laurent.Vivier@...154...>
- Date: Tue, 16 Sep 2008 16:56:25 +0200
- Message-id: <1221576985.4172.26.camel@...156...>
- In-reply-to: <20080912060352.GA3733@...172...>
- References: <1221119881.4145.13.camel@...156...> <48C94529.40307@...124...> <1221160674.4124.6.camel@...156...> <20080912060352.GA3733@...172...>
Le vendredi 12 septembre 2008 à 08:03 +0200, Wouter Verhelst a écrit :
> 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.
OK.
Is "directory" a good name for this 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).
OK
> The 'flags' field in the negotiation should get another flag, signalling
OK
> 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.
Is the protocol already includes this behavior (client returns known
flags) ? if yes, where ? I didn't find it. If not, I don't see how to
add it without breaking all.
>
> > > > - 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
> ;-)
OK
> > > > - 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.
OK
> > > > - 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 :-)
in progress...
> > > 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.
OK
Regards,
Laurent
--
----------------- Laurent.Vivier@...154... ------------------
"La perfection est atteinte non quand il ne reste rien à
ajouter mais quand il ne reste rien à enlever." Saint Exupéry
Reply to: