RE: iSCSI: problem with LUN discovery

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

YP, we are on the same page.

.
.
.
John L. Hufferd


"Y P Cheng" <ycheng@advansys.com>@ece.cmu.edu on 10/05/2000 09:50:50 AM

Sent by:  owner-ips@ece.cmu.edu


To:   <ips@ece.cmu.edu>
cc:
Subject:  RE: iSCSI: problem with LUN discovery



> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> John Hufferd/San Jose/IBM
> Y P Cheng,
> OK, now I have detected an important communication problem here.  What
you
> are calling a LUN is not what the rest of us folks (or at lest me) call a
> LUN.  <snip> <snip>

Thank you for a nice summary of the definitions of LU and LUN.  No, we did
not have disagreement.  It is only mis-communication.  (If I did not real
your email incorrectly.)

LUN, the address of an LU, is embedded in an iSCSI command PDU or an FC
command frame to direct a SCSI command to the LU.  What confuses people is
that the SCSI LU today is virtual and has nothing to do with real physical
devices.  The virtual to real mapping will be done by system administrator
who reconfigures new and replaces bad SCSI devices.  Each SCSI device in
iSCSI should have a GUID.  However, a physical device is not visible to an
application. Software like Veritas adds one more layer of virtualization by
taking the virtual LU's and making them virtual volumes.

All I said was that the LUN needs not be unique world wide.  An LU has its
unique attributes that can be obtained by page 0x83h.  A login or CONNECT
discussed in another thread provides the TCP connection to reach an iSCSI
node.  The connection is used by the TCP/IP transport.  Within an iSCSI
PDU,
an LUN is specified.