[storage-discuss] Question on iSCSI/FCoE packages - old stuff vs. COMSTAR

[Peter Cudhea]

 From the list of enabled services, your system is already set up to use 
COMSTAR iSCSI.  Using COMSTAR iSCSI requires the "stmf" and 
"iscsi/target" services and requires disabling the "system/iscsitgt" 
service, both of which you have done.

Other comments are inline.

Jim Klimov wrote:
> As I read reviews, it seems that COMSTAR implementations are faster and better
> in many respects than the older iSCSI stuff integrated around build 100. And that
> these implementations can conflict, too, so only one service of each type should
> be enabled.
>
> Are these impressions correct?
>
> I want to hop on this train and begin playing around with iSCSI-exported
> volumes. They would be imported by this same server and by other similarly
> configured servers (testing VBox failover/migration/LB ideas). Also we want
> to test clustered filesystems (in Solaris and/or other OSes) backed by iSCSI.
>
> My snv_117 systems after a number of upgrades has the following relevant 
> packages:
>
> [root at thumper ~]# pkginfo | egrep -i 'iscsi|fcoe|comstar|stmf'
> system SUNWfcoe Sun FCoE Transport Driver
> system SUNWfcoet Sun FCoE COMSTAR Driver
> system SUNWfcoeu Sun FCoE Port Management Library
> system SUNWiscsidmr Sun iSCSI Data Mover (Root)
> system SUNWiscsidmu Sun iSCSI Data Mover (Usr)
> system SUNWiscsir Sun iSCSI Device Driver (root)
> system SUNWiscsitgtr Sun iSCSI Target (Root)
> system SUNWiscsitgtu Sun iSCSI Target (Usr)
> system SUNWiscsitr Sun iSCSI COMSTAR Port Provider (root)
> system SUNWiscsitu Sun iSCSI COMSTAR Port Provider
> system SUNWiscsiu Sun iSCSI Management Utilities (usr)
> system SUNWstmf Sun Common Multiprotocol SCSI Target
> system SUNWstmfu Sun Common Multiprotocol SCSI Target Libraries and Tools
>
> ...and services:
>
> [root at thumper ~]# svcs -a | egrep -i 'iscsi|fcoe|comstar|stmf'
> disabled 4:38:04 svc:/system/iscsitgt:default
> online 4:38:34 svc:/network/fcoe_config:default
> online 4:38:35 svc:/network/iscsi/initiator:default
> online 4:38:43 svc:/system/stmf:default
> online 4:38:43 svc:/network/iscsi/target:default
>
> QUESTIONS:
>
> Which packages and services are safe/required to remove if I want COMSTAR
> only? (And should I want COMSTAR only? ;) ) Which should be added/checked?
>   
It is safe and not required to remove the packages SUNWiscsitgtr and 
SUNWiscsitgtu.   Nothing else is required for basic operation.

For troubleshooting and debugging, I find it useful to load the 
"sg3_utils" package onto the initiator system and the "wireshark" 
network snooping package onto a system from which I can observe the 
network traffic.  Neither of these is needed except for developer 
investigations.
> Does COMSTAR play well with "zfs set shareiscsi=on" ?
>   
No.  The shareiscsi feature is currently restricted to the 
"system/iscsitgt" service.  For COMSTAR, one must do the steps manually: 
create a zvol using the zfs command; create an SBD logical unit for that 
zvol using sbdadm; and create a view for that logical unit using stmfadm.
> Does this iSCSI implementation work for shared-access (clustered) filesystems
> such as whatever is supported/runs on OpenSolaris SXCE (in fact - what, namely? ;) )
>   
The COMSTAR Logical Unit support (the sbd module) does support SCSI 
Persistent Group Reservations (PGR) which is what is required for 
clustered/shared access.  COMSTAR is currently going through several 
"cluster validation" suites such as Microsoft's WHQL, but results are 
not yet complete.   We would be interested in hearing your experiences 
in this area.
> What caveats/bugs/tricks are to be expected (and perhaps documented already?)
>
> Thanks,
> //Jim
>
> PS: Reposted for more relevance from general discussions list. Sorry about that.
>