RE: iSCSI boot

["Douglas Otis" <dotis@sanlight.net>]

David,

Rather than attempting to replicate a micro NFS client level of complexity
in a boot NAS, A DUA to obtain parameters should allow immediate use of a
SAN.  As far as the level of complexity, the means of obtaining the required
access together with code exists today.  It is simply a matter of defining
the structures.  Yes, it is different from starting with a NAS.  DHCP passes
a limited number of parameters and will be overwhelmed by the demands for
starting an iSCSI session.  LDAP can easily accommodate these demands
without one bit of the protocol modified or new DHCP parameters defined.
There could simply be a table defined in the boot image for that matter if
LDAP seems to difficult but that seems difficult to manage.

Doug


> Douglas Otis wrote:
> > I think you misunderstand where this code would exist.  It would not be
> > within the DHCP/PXE PROM code.
> >
> > Use the existing environment and previously defined parameters in
> > conjunction with existing servers and existing protocols.
>
> I clearly don't understand your point.  The purpose of the iSCSI boot
> draft is to define a mechanism to determine where the "root" disk is
> using standard protocols, most notable DHCP. Once the root disk is
> accessed and the operating system is loaded, everything is done
> using the naming and discovery mechanisms that will be defined.
>
> Using sophisticated protocols like LDAP may be appropriate once a
> kernel is loaded and should be defined as part of the naming and
> discovery design, but it is not a boot issue. The richness of LDAP
> is complete overkill for the initial boot environment.
>
> As a practical example, NFS clients today can boot using either
> bootparams or DHCP to load the initial root partition, once the
> kernel is loaded it is common to "remount" the root partition
> using the full NFS mount mechanisms. An iSCSI initiator could
> do the same thing to "relogin" and use the full set of options
> that may not be present in the boot environment.
>
> 	-David
>