if global setting auto_add_mapped_luns is true (the default), then adding a storageobject to a target will automatically add it to each acl. If this is not set then each lun needs to be mapped to each acl, and the mapping can specify a different lun.

Just in describing this now, it seems clunky. It should be possible to easily add a storageobject directly within the acl without adding it to the target first. I've added an upstream issue:

https://github.com/agrover/targetcli-fb/issues/13

also, document mapping use case better:

https://github.com/agrover/targetcli-fb/issues/14

but this bug is not valid because we do support mapping LUNs on a per-initiator basis.

As for the ACL name, they may have decided to call it this because on other fabrics such as iscsi, this is also where authentication info (user/password) is managed. "acls" is really short for something like "per-initiator settings".

I am confused.

I tried these commands to assign a LUN to certain target which already have 1 LUN mapped.
====
/backstores/fileio create disk2 /tmp/fcoe-lun2 10240M
/tcm_fc/20:00:00:1b:21:59:12:36/luns/ create /backstores/fileio/disk2 100 false
====

But I failed to find any commands for mapping:
====
/tcm_fc/20:00:00:1b:21:59:12:36/acls/ create 10:00:00:05:1e:8f:fa:da
====
or
====
/tcm_fc/20:00:00:1b:21:59:12:36/acls/ create 10:00:00:05:1e:8f:fa:db false
====

Will not work, as ACL entry already exists.

I am out of patient for document digging or command guessing.
Can you advise of which command for LUN mapping?

mapped luns are created within the ACL config node.

/backstores/fileio create disk2 /tmp/fcoe-lun2 10240M
/tcm_fc/20:00:00:1b:21:59:12:36/luns/ create /backstores/fileio/disk2 100 false

set global auto_add_mapped_luns=false

/tcm_fc/20:00:00:1b:21:59:12:36/acls/ create 10:00:00:05:1e:8f:fa:da

/tcm_fc/20:00:00:1b:21:59:12:36/acls/10:00:00:05:1e:8f:fa:da/ create 0 100

That ACL should now show mapped_lun0 for that initiator.

Thanks for the tips.

I will try to draft out a document for fcoe-target-utils in my document week. (the week after RHEL 6.3 GA).

Keep this bug open for document update.

Andy,

Please consider organize these lines to manpage:

$be_type   # Back-end type: pscsi/block/fileio
$lun_name  # file which save real data.
$disk_name # Storage Object for fcoe-tgt internal use.
$h_wwpn    # FCoE HBA WWPN (initiator side)
$t_wwpn    # FCoE HBA WWPN (fcoe target side)
$h_lun_id  # The LUN ID host will got.
$t_lun_id  # The LUN ID internally used by fcoe-tgt

LUN Creating:
targetcli /backstores/$be_type create $disk_name $lun_name ${size_bytes}B

LUN Masking:
set global auto_add_mapped_luns=false
/tcm_fc/$t_wwpn/luns/ create /backstores/$be_type/$disk_name
# you will be informed with $t_lun_id

LUN Mapping:
targetcli /tcm_fc/$t_wwpn/acls/ create $h_wwpn
targetcli /tcm_fc/$t_wwpn/acls/$h_wwpn/ create $h_lun_id $t_lun_id

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Hi Maurizio,
Do you plan to fix this bug on 6.10?

Moreover, in the storage administrator guide [1], the "Map a backstore to the target instance" is mentioned. But it doesn't cover the LUN MASKing which mentioned in #c5.

[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/fcoe-config#idm139814836044112

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/