From: Paul v. B. <Paul.Vonbehren@Sun.COM> - 2003-12-16 22:07:39
|
David Dillard wrote: > 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. That seemed like the most appropriate approach. > > 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 Yes > 3. Expose LU > 4. Unexpose LU No, we are assuming this is managed from targets (LUN Masking). > > Anything else? Looks like we can provide all the other mandatory interfaces. > > > PS: Why oh why didn't you guys start shooting arrows at IMA earlier??? Funding :-! Paul > > > > >>-----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. >> |