SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: More on iSCSI boot



    
    
    David,
    
    The trouble with our boot is two-fold:
    
    -the SCSI boot - unlike the network boot is unbounded (there is no such
    thing as an image).
    -even if we would like to standardize a "primary" or "minimal" boot we have
    no good understanding (experience)
    of how this will interact with the iSCSI security mechanisms.
    
    Julo
    
    Black_David@emc.com on 31-05-2001 05:49:57
    
    Please respond to Black_David@emc.com
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  More on iSCSI boot
    
    
    
    
    Let's start with a simple boot from a disk - the system
    BIOS reads the boot sector(s) off of the disk drive,
    loads and runs it/them.  That primary bootloader then
    handles whatever else is necessary based on the ability
    to do disk reads (a secondary bootloader and/or other
    things may be involved).  On Intel systems, it's generally
    a combination of the system BIOS and card BIOS that
    make the disk reads work.  Simplifying assumptions
    are common (e.g., boot from LUN 0 on the first SCSI
    target found).  The goal of the iSCSI boot draft is
    to explain how to make this "simple boot from a disk"
    mechanism work when the boot disk is attached via iSCSI.
    
    An iSCSI adapter has some things to do in order to make
    this work, e.g., it has to log into the target before disk
    reads can be issued.  I tend to believe that "Don't do this
    (i.e., try to boot over iSCSI)" is not an acceptable answer.
    
    In the message that started this whole boot discussion, I
    suggested that
    
         Using DHCP to find SLP to find the boot device seems
         both clumsy and an invitation to problems (one more
         thing that can break and prevent booting),
    
    I think that's doubly true if LDAP is used instead of SLP.
    David Robinson's messages support my inclination to reuse
    DHCP option 17 (Root Path) by defining iSCSI syntax
    for it.  Between that, any TCP parameters that one wants to
    set through DHCP, and iSCSI parameters that can be defaulted,
    it should be possible to get the first disk reads done
    through iSCSI.
    
    As has been pointed out, booting is often poorly secured in
    general.  While it'd be nice to change this, iSCSI will face
    the same pressures that other boot mechanisms face - keep
    it simple, get the boot image loaded, and let it do something
    fancier.  Any signature/validation of the boot image will be
    above the level of iSCSI.  Somehow, I don't expect to find
    implementations of ESP in card BIOSes anytime soon.
    
    If implementers want to use DHCP and TFTP to boot, I don't
    see any point in stopping them, but I don't think either should
    be mandated.  DHCP has centralized administration advantages,
    and TFTP is a simple way to download code, but both are "one
    more thing that can break and prevent booting" and hence may
    not be used all the time.
    
    Comments?
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:35 2001
6315 messages in chronological order