Hi, Bellinger:
Thanks for your detail explanation.
Yes, I means initiator access group is like this. Similar to what you described. for example: LUNS in group A in a FC target could be access by a initiator A, LUNS in group B in a FC target could be access by a initiator B. LUNS in group A in a FC target could not be access by a initiator B. LUNS in group B in a FC target could not be access by a initiator B. the FC target is the same target.
I think the initiator access groups could be implemented in the python-rtslib or LIO kernel code. Do you have any suggestion? Do you have plans to add this feature?
Regards
Shuo
-----Original Message-----
From: Nicholas A. Bellinger [mailto:nab@xxxxxxxxxxxxxxx]
Sent: 2017年3月21日 15:03
To: Lv, Shuo
Cc: target-devel@xxxxxxxxxxxxxxx; linux-rdma@xxxxxxxxxxxxxxx
Subject: Re: fc access control issue
Hi Shuo,
On Tue, 2017-03-21 at 00:41 +0000, Lv, Shuo wrote:
> Hi,
> When I use tcm_qla2xxx target, I found that the granularity for
> the FC access control is very large and it is target-level. The LUNS
> in the target could be all accessed by initiator or the LUNS in the
> target could not be accessed by initiator. I don't know If the
> tcm_qla2xxx could create multiple targets for the same port?
Multiple targets per port is accomplished with a FC switch feature
called N_Port ID Virtualization (NPIV).
This allows multiple virtual WWPNs to be configured on a single physical
FC port, each with it's LIO target configfs namespace residing
under /sys/kernel/config/target/qla2xxx_npiv/$NPIV_WWPN/, et al.
Support for tcm_qla2xxx/NPIV was added in mainline v4.1 here:
https://www.mail-archive.com/linux-scsi@xxxxxxxxxxxxxxx/msg25618.html
and although information is pretty scarce how to actually use
tcm_qla2xxx/NPIV, there was some discussion back in 2015 about how it
currently works from an end-user perspective here:
https://lists.fedorahosted.org/pipermail/targetcli-fb-devel/2015-May/000157.html
> Could we implement the group level access control? Like a group in a
> target could be access by a initiator, another group in the same
> target could be access by other initiator? Any suggestion is
> welcome.
>
I assume you mean a initiator access group abstraction, eg: where a
initiator group is associated with a specific target endpoint, and all
initiators associated with the group have ACLs added to the endpoint.
targetcli itself doesn't support initiator access groups, but there are
multiple vendors who have built initiator access group constructs into
their products atop python-rtslib, using vanilla LIO kernel code.
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
