David McMillen, on 06/10/2009 07:07 AM wrote:
Chris Worley wrote:
On Thu, Nov 20, 2008 at 1:06 PM, Vu Pham <vuhuong at mellanox.com
<http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general>> wrote:
>/
/>/ Hi James,
/>/
/>/ it's srp_daemon and ibsrpdm bug. We'll try to fix it to provide zoning thru
pkey.
/
I don't think pkeys are the answer to zoning, as I don't see a way to
tie a specific disk or partition to a pkey. At one point I tried to
tie IB ports to pkeys, but found that all levels of the SRP stack
needed to be pkey-aware. It looks like a daunting task, and probably
not what pkeys were intended to do.
I think SCST "security groups" are the intended way to zone. The
scst/README says:
...
2. Initiator-oriented. In this mode you define which devices and
their LUNs are accessible for each initiator. In this mode you should
createfor each set of one or more initiators, which should access to
the same set of devices with the same LUNs, a separate security group,
then add to it available devices and names of allowed initiator(s).
...
# echo "add_group
Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz"
>//proc/scsi_tgt/scsi_tgt
/# echo "add dev1 0"
>//proc/scsi_tgt/groups/Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz/devices
/# echo "add dev2 1"
>//proc/scsi_tgt/groups/Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz/devices
/
# echo "add_group spec_ini" >/proc/scsi_tgt/scsi_tgt
# echo "add iqn.2007-05.com.example:storage.disk1.spec_ini.xyz"
>//proc/scsi_tgt/groups/spec_ini/names
/# echo "add dev2 0" >/proc/scsi_tgt/groups/spec_ini/devices
...
But, I don't understand how the zoning example selects the initiator
visibility... I'd hope w/ IB this could be done w/ the port GUID of
the initiator. The example uses the name of
"iqn.2007-05.com.example:storage.disk1.spec_ini.xyz" to specify the
initiator. I'm guessing "iqn.2007-05.com.example" specifies the host
name of the initiator, but not a clue what
"storage.disk1.spec_ini.xyz" means.
Chris
You got pretty close. I think there is at least one typographical error
in the explanation above, but let me try to explain it differently.
The groups are used to create different sets of LUNs that are presented
to the initiators that match a group. When a login request comes in,
scst is asked to find the group given a name. You can get scst to
output a message like
Using security group "Default" for initiator "xxx"
on the console. The value in "xxx" (not really xxx, but dependent upon
the target code using scst) is matched against all of the entries in the
"names" pseudo file under each group's directory. The first group that
matches is the winner. The LUNs defined by the entries in the "devices"
pseudo file under that same group will be the only LUNs seen for that
session. If no group has a line in "names" that matches, then the group
"Default" is used. There is a "names" pseudo file here but it's
contents are ignored -- everybody is a winner matching the Default group.
The name of the group is completely arbitrary and meaningless to scst
other than to differentiate groups. If you intend to have a unique
group for every initiator, then you could use the same value you will
write to "names" as the name of the group, but you could just as easily
just generate random names that are unique.
If you want a particular LUN to show up in more than one group, you have
to add it to "devices" for every group that will use it. Also, if you
want that LUN to have the same LUN number, you have to arrange that as well.
It is probably worth noting that there can be problems if a group does
not have a device defined for LUN 0. It works, but there are initiators
and user-level programs that issue SCSI commands and expect to get
something when LUN 0 is addressed. All real devices have some kind of
response at LUN 0, even if it is an odd SCSI device or a zero byte /
offline disk.
Back to the "xxx" mentioned above, I don't know what the code you have
uses as the key for scst to find a group. That is why I suggested you
check your dmesg output, and you might have to enable some verbose/debug
output. I believe this changed at least once, and in our implementation
we are reworking it so we can have highly selective LUN masking against
the initiator/target pair.
This is an excellent explanation! I can only add to it that "xxx" is a
transport specific name. For iSCSI it is an iSCSI name, like
iqn.2007-05.com.example:storage.disk1.spec_ini.xyz, for SRP it is a port
name.
Dave
------------------------------------------------------------------------
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
