<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Chris Worley wrote:
<blockquote cite="mid4A2F1E2D.1050205@systemfabricworks.com" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<pre>On Thu, Nov 20, 2008 at 1:06 PM, Vu Pham <<a
href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">vuhuong at mellanox.com</a>> wrote:
><i>
</i>><i> Hi James,
</i>><i>
</i>><i> it's srp_daemon and ibsrpdm bug. We'll try to fix it to provide zoning thru pkey.
</i>
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"
><i>/proc/scsi_tgt/scsi_tgt
</i># echo "add dev1 0"
><i>/proc/scsi_tgt/groups/Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz/devices
</i># echo "add dev2 1"
><i>/proc/scsi_tgt/groups/Default_iqn.2007-05.com.example:storage.disk1.sys1.xyz/devices
</i>
# echo "add_group spec_ini" >/proc/scsi_tgt/scsi_tgt
# echo "add iqn.2007-05.com.example:storage.disk1.spec_ini.xyz"
><i>/proc/scsi_tgt/groups/spec_ini/names
</i># 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</pre>
</blockquote>
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.<br>
<br>
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<br>
<br>
Using security group "Default" for initiator "xxx"<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Dave<br>
<br>
<br>
</body>
</html>