Syslinux - Oct 2009 - How to support iSCSI multipath...

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.

Does anybody have any advice about how to go about this, or whether it is even 
feasible?

Thanks in advance for any help, and thank you for syslinux!

Alex

Hello Alex,

In regards to your question regarding passing multiple paths for
fault-tolerance (I assume) in the iBFT:

A slight correction: gpxelinux.0 = undionly.kkpxe (gPXE) + pxelinux.0
(PXELINUX)

I'm not sure why you'd wish to load a filename into your iBFT directly.
Were you thinking of customizing the iBFT and parsing it in your initrd?

The gPXE SAN-boot obeys the routing information that gPXE has.  Never
mind which interface(s) DHCP is performed on.  Whichever interface is
the first match for the proper route to the SAN, that'll be the
interface used.

Perhaps you'd be inclined to 'wget' or 'curl' further
information from
some instructional server in your initrd in order to setup multiple
paths?

I don't recall just at the moment if the iBFT can have multiple paths in
it.  If you think it can, could you please pass along a reference?

- Shao Miller

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>