[iscsi-mgmt-api-reflib] RE: feedback requested regarding IMA plugins for software iSCSI i nitiators

[David D. <dav...@ve...>]

On the particular case of a not being able to show link aggregation I'd say
fine, just have a 1 to 1 mapping from LNP to PNP.

More generally, I have a question: what functionality ARE you planning on
providing in the plugin?

It seems like it'd be:

  1. List of targets
  2. SCSI commands to targets
  3. Expose LU
  4. Unexpose LU

Anything else?



PS: Why oh why didn't you guys start shooting arrows at IMA earlier???



> -----Original Message-----
> From: Paul von Behren [mailto:Paul.Vonbehren@Sun.COM] 
> Sent: Tuesday, December 16, 2003 3:52 PM
> To: David Dillard
> Cc: 'David W.'; ip-...@sn...; 
> isc...@li...
> Subject: Re: feedback requested regarding IMA plugins for 
> software iSCSI i nitiators
> 
> 
> 
> David Dillard wrote:
> 
> > Reply inline below... 
> > 
> > 
> >>Representation of IMA 1.0 Constructs in a Software Initiator Plugin
> >>
> >>The IMA 1.0 specification outlines a model for management of iSCSI 
> >>initiators that is based on underlying constructs involving 
> physical 
> >>HBAs (PHBA),  physical network ports (PNP), logical HBAs (LHBA), 
> >>logical network ports (LNP), and network portals (NP) Of these 
> >>constructs, only the LHBA seems to fit well in a software initiator 
> >>plugin environment.
> > 
> > 
> > Surprise! I disagree with this. :-)
> > 
> > - A NIC qualifies as a PHBA.
> > - The ports on a NIC are certainly PNPs.
> > - A link aggregate of ports (originally defined for TCP/IP) 
> is an LNP.
> > - A network portal is an iSCSI construct, not an IMA 
> construct, so it 
> > applies to any iSCSI implementation ;-)
> > 
> 
> The problem is that IMA (and iSCSI in general) require APIs 
> that may not exist in a legacy TCP/IP stack and reproduces 
> capabilities that may may exist in the stack.  So those of us 
> trying to leverage existing software need a way to get 
> reasonably close to IMA without rewriting the TCP/IP stack.  
> There is a certain amount of detail (such as link 
> aggregation) that is not exposed today in TCP/IP and we will 
> not expose in our iSCSI implmentation.
> 
> So I'm with David W here; I'd like to see a recommended 
> approach for plugin authors to say - this plugin does not 
> offer fine-grained control over the HBAs, but does comply to 
> rest of IMA.  I think also need a property to let a client 
> know they are dealing with this type of plugin.
> 
> Paul
> 
> > 
> >   
> > 
> >>Existence and management of the other entities make sense when an 
> >>iSCSI HBA is present.
> >>However, when a software initiator is present, the 
> initiator functions 
> >>as just another TCP/IP network protocol, unaware and 
> unconcerned about 
> >>the underlying physical HBAs, physical ports, etc.
> > 
> > 
> > The initiator may not need to know about these things to 
> function, but
> > management software very much wants to know about such things.
> > 
> > 
> > 
> > 
> >>A software initiator is subject to all the 
> >>underlying networking configuration just as any other 
> >>protocol in the machine.
> >>In fact, in a software initiator situation, management of 
> >>things like IP addresses, gateways, etc, from an IMA context 
> >>is probably undesirable since the changing of these values 
> >>might affect other protocols.
> > 
> > 
> > True.  That's why the IMA provides a way for the plugin to 
> communicate to a
> > client what's settable and what isn't settable.  NONE of 
> the things you
> > mentioned is REQUIRED to be settable.  Next to nothing in the IMA is
> > REQUIRED to be settable.
> > 
> > 
> > 
> > 
> >>This is also not the norm for 
> >>other storage networking protocols such as NFS.  Furthermore, 
> >>even accurate enumeration of the actual physical HBAs, 
> >>physical ports, etc, from a software initiator plugin 
> >>perspective may be very difficult when one considers the 
> >>complex networking configurations that may arise, and the 
> >>fact that some information (i.e. what actual hardware exists, 
> >>link speeds, etc.) is only available to the device driver itself.
> > 
> > 
> > Sure.  So, the device driver should be enhanced to expose 
> the necessary
> > information to the plugin via ioctls or other means.
> > 
> > 
> > 
> > 
> >>Unfortunately, because of the way the IMA was designed, a 
> >>useful plugin cannot ignore the construct of the PHBA and 
> >>simply return a NULL list in response to the 
> >>IMA_GetPhbaOidList() call, since the iSCSI target discovery 
> >>mechanisms are based on a PHBA.
> > 
> > 
> > This is true.  Nor should it.  The PHBA is the physical 
> medium upon which
> > physical network ports are mounted.  For a software 
> initiator these are
> > NICS.
> > 
> > 
> > 
> > 
> >>The other constructs such as 
> >>the NP, LNP, and PNP might be ignored, in which case the 
> >>corresponding IMA_Get*OidList() calls would return NULL lists 
> >>for the plugin.
> > 
> > 
> > That would be very bad karma :-)  And probably something 
> that I should
> > revise the spec to prohibit.
> > 
> > 
> > 
> >>However, this was clearly not the intent of 
> >>the IMA, as detailed in the UML Class Relationship Diagram on 
> >>p. 12 of the IMA specification, and the definition of these 
> >>constructs.  As a result it's not clear what implications 
> >>such an approach (i.e. having a PHBA present and other 
> >>constructs absent) would have to applications who use an IMA 
> >>containing this type of plugin.
> >>
> >>For these reasons, one possible approach for a software 
> >>initiator is to virtualize the needed constructs as follows:
> >>
> >>   1. A single virtualized PHBA that represents the 
> software initiator
> >>   2. A single virtualized PNP that hangs off the virtualized PHBA.
> >>   3. A single LHBA. Software initiators typically must present
> >>      themselves to the operating system just as another SCSI host
> >>      adapter, and in this way, fit the definition of 
> >>"Logical HBA", as
> >>      outlined on p. 10 of the IMA specification, that states, "A
> >>      logical HBA (LHBA) is a representation of a parallel 
> SCSI HBA to
> >>      the operating system".
> >>   4. A single LNP that hangs off the Logical HBA, and maps to the
> >>      single virtualized PNP.
> >>   5. A single virtualized NP, that represents any real 
> network portal
> >>      that may be used by the software initiator.
> >>
> >>Taking this approach will have the drawback that any 
> >>management application that wishes to show targets or LUNs 
> >>mapped to a particular PHBA, PNP, network portal, etc, or 
> >>otherwise manage the underlying IP network will not be able 
> >>to do so.  In addition, the IP addresses, MAC addresses, 
> >>physical link information, etc. will not be real values, but 
> >>will contain zeros or invalid data that is easy to recognize. 
> >>However, as was stated earlier, in the software initiator 
> >>case, well-known utilities already exist (i.e. ifconfig, 
> >>netstat, etc) to examine and manage the underlying network 
> >>infrastructure, so these drawbacks seem to be mitigated.
> > 
> > 
> > Virtualizing physical objects is something to be avoided.  
> The FC HBA API
> > suffered from this which is why both physical and logical 
> objects are in the
> > IMA.
> > 
> > There are ways for a software initiator to satisfy the 
> requirements of the
> > IMA, as I've outlined above.  I STRONGLY urge you to not subvert the
> > intented functionality in your plugin.
>