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

iSCSI Boot




Hello!

(A similar mail was posted some days ago on the debian-boot mailing
list - the time when I did not know that debian-boot is not about
debian boot - and FJP proposed to send the mail to this address. See
http://lists.debian.org/debian-boot/2008/02/msg00771.html)

I'm interested in getting iSCSI boot to work.  There is one challange:
multipath must also work during boot phase.  After some research and
development, a prototype in my sandbox is working.  Maybe some ideas
and source code are of general use:

=== Handling Parameters

The first issue I found was the handling of different protocols for
boot disk detection.  At the moment there is some strange
implementation which allows local and nfs - with strange I mean, that
e.g. root=/dev/nfs is valid and does mostly the same as boot=nfs.
There is no general solution for different boot protocols possible
with the current implementation - except to introduce a new set of
parameters for each method.

In my opinion there should be a more general solution.  My proposal is
to have a root file system parameter like
   rfs=local:path=/dev/hda1;flags=noatime
or
   rfs=iscsi:path=/dev/mapper/dnsserver-root1;\
	portals=192.168.225.1,192.168.226.1;\
	localiqn=iqn.1987-05.com.company:01.86d448c3296
or
   rfs=nfs:path=/some/path;server=192.168.199.1
or
   rfs=someotherprotocol:key1=value1;key2=value2

Some ideas about this can be found in the PDF description (see
Reference).

=== Multiple Network Adapters

To implement multipath over iSCSI, there is a need to setup multiple
network devices during boot phase.  AFAIK the current implementation
of initramfs-tools only supports exactly one network device - which
can be configured in the 'initramfs.conf' under 'DEVICE'.

For my tests the DEVICE was renamed in NETWORK_DEVICES and adapted the
scripts that this can handle a list instead of only one entry.

This works for iSCSI, but it might be a problem with other current
implementations that assume only one interface.  Example: how should
the last lines in the 'configure_networking()' function should be
handled:

        # source relevant ipconfig output
        . /tmp/net-${DEVICE}.conf

This only makes sense (when looking at the ipconfig output) when there
is only one network device.  My proposal is, to move the sourcing of
the ipconfig output to the modules that really need it.  NFS will then
source it, because it depends on ROOTSERVER and ROOTPATH; iSCSI will
not source it, because there is no need.

(The current implementation only works when using some automatic ip
configuration like DHCP.  Using the ip= parameter only allows to
supply exactly one ip configuration for one network device.)

=== iSCSI Boot Script

The iSCSI boot script itself is executed during the local-top script
phase (iSCSI is handled here the same way as e.g. FC storage).  This
was done, because the local and iSCSI boot share most things, except
the iSCSI specific network setup and detection.  The advantage of this
is, that also the other parts - like multipath-tools-boot - can be
used without any change.

The script is straight forward: it sets up the initiatorname, starts
the iscsid and logs in with the help of iscsiadm.

The iscsid / iscsiadm was chosen over iscsistart, because iscsistart
cannot handle multiple connections to an iSCSI storage very well / at
all (???) and it is even not part of the Debian open-iscsi package.

The tricky part is switching to new root file system.  The iscsid must
be restarted when system boots up.  This must be done, because the new
iscsid should use the new environment with syslog and other things.
In the local-bottom phase, also the iscsi environment is copied over
to the new root disk.

=== Package architecture

I think, it makes sense to have an own package, where the special
iSCSI scripts should be put in - like 'multipath-tools-boot' it can be
named 'open-iscsi-boot'.

=== Current State

Everything is alpha.  'rfs' command line handling for iSCSI partially
implemented. NETWORK_DEVICES instead of DEVICE.
And: have some machines running using the current implementation.

ToDo / Further Ideas:
* Evaluate root-path DHCP response as the 'rfs' string

===

What do you think of adding iSCSI boot to initramfs-tools and adding a
package 'open-iscsi-boot'?

Do you see any problems with the patches?  Any hints, remarks?

When you say the general idea is ok, I'll can spend some time
implementing the rest.


Cheers.

Andreas Florath

References: The patches can be found in
http://www.flonatel.org/iscsi/debian-initramfs-tools



Reply to: