[syslinux] [PATCH] How to support iSCSI multipath...

[Alex Zeffertt]

Alex Zeffertt wrote:
> Hi Bootmeisters,
> 
> I am using gpxelinux.0 + sanboot.c32 to boot a diskless machine into Linux.  I 
> would like to use device-mapper-multipath to provide fault tolerant access to 
> its root disk.
> 
> Although I am able to do this by hardcoding the additional paths in the initrd, 
> it would be better if the bootloader could pass the information in the iBFT 
> (iSCSI Boot Firmware Table).  However, at the moment gpxelinux.0 can only build 
> iBFTs with one NIC and one target.
> 
> As I understand it, gpxelinux.0 consists of two parts linked together: 
> pxelinux.gpxe (taken from the etherboot project); and pxelinux.0.  The 
> pxelinux.gpxe part runs first and extends the TCP/IP stack of the PXE 
> implementation in ROM.  It then runs a script which launches pxelinux.0. 
> pxelinux.gpxe provides the iSCSI protocol support which can later be used by the 
> sanboot.c32 comboot module.
> 
> When "sanboot.c32 iscsi:<tgtip>:<prot>:<port>:<lun>:<iqn>" is run, pxelinux.0 
> passes control back to the pxelinux.gpxe component to build the iBFT.  Although 
> the target to write to the iBFT it given explicitly, the NIC and IP 
> configuration are implicit, and pxelinux.gpxe assumes that these should be the 
> NIC that DHCP'd, and the IP configuration provided by the DHCP server.
> 
> In order to support multipath I need to make this more flexible.  Ideally 
> sanboot.c32 would support an invocation like this:
> 
>    sanboot.c32 ibft:<filename>
> 
> that would cause it to collect tftp://<next-server>/<filename>, load it into 
> memory, read it to determine the NIC and config to use, and then proceed as 
> before by logging into the LUN and jumping to its MBR.
> 

Hi again,

I've been looking at the source and I've come up with a first stab at 
implementing the "sanboot.c32 ibft:<filename>" invocation.  I'd really 
appreciate it if someone could look at the attached patch and tell me if I'm 
going about it the right way - I'm totally new to syslinux programming.

The benefit of having the iBFT in a file on the TFTP server, rather than 
generated on the fly by gpxelinux.0, is that it gives you more control over how 
the OS boots.  For example, if the OS supports multipath, you can add a 2nd 
target in the iBFT, representing an alternative path to the same LUN, and the OS 
will boot using redundant paths.  At the moment, in order to do this you need to 
put the 2nd path to the LUN in the LUN itself, which means the machine won't 
boot if the LUN is moved.

Unfortunately there is a bit of a hack in the code.  Although gpxelinux.0 uses 
the iBFT to determine the target (it just looks at the first one of the two at 
the moment) it does not read the iBFT to determine which NIC to use and how it 
should be configured.  This is because it cannot control which NIC is used as it 
may only have a BIOS driver for the one that did the DHCP request.

However, the patch does allow complete flexibility in what iBFT is passed to the 
OS, and therefore it allows you to configure how the OS does it's iSCSI boot 
just by editing files on the PXE server.

Comments appreciated....

Alex
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <http://www.zytor.com/pipermail/syslinux/attachments/20091002/70b55b19/attachment.ksh>