Bug 828697

Summary: Need documnet for fcoe-target-utils LUN Mapping.
Product: Red Hat Enterprise Linux 6 Reporter: Gris Ge <fge>
Component: fcoe-target-utilsAssignee: Maurizio Lombardi <mlombard>
Status: CLOSED WONTFIX QA Contact: Martin Hoyer <mhoyer>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.3CC: mlombard, xhe
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-06 11:41:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gris Ge 2012-06-05 08:23:16 UTC
Description of problem:
Current fcoe-target-utils (RHEL 6.3 GA) force host ID is same as target LUN ID.
Which it not how storage array should be.

This command create a LUN 200 in target, but all host will get LUN 200.
===
/tcm_fc/20:00:00:1b:21:59:12:36/luns/ create /backstores/fileio/disk2 200 false
===

For EMC storage array, there are two terms for this thing:

1. LUN Masking: Who can access to this LUN via which storage array frond-end.
2. LUN Mapping: What LUN ID will a host got.

For NetApp storage array, they are no target LUN ID term, so they merge LUN masking into lun mapping:
===
lun map  /vol/vol_storageqe/storageqe-05-01 storageqe-05 01
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^ ^^
#              LUN Name                      WWPN Group  Host LUN ID
===

Harm we cannot get this feature:

1. Most boot from SAN need LUN ID is 0. (Even modern HBA support change in BIOS)
   But storage administrator still follow this rule.

2. Many OSs don't support Host LUN ID larger than 512.
   This is the most big impact. (RHEL 6 don't support it by default)

Meanwhile, I would like to request developer follow the common name scheme of SAN. ACL is not a good name for LUN Masking.


Version-Release number of selected component (if applicable):
fcoe-target-utils-2.0rc1.fb10-5.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1. 
2.
3.
  
Actual results:


Expected results:


Additional info:

Please treat this feature as medium or high priority. The most important impact for user/customer is: they will got issue if they created 512+ LUNs by fcoe-target-utils.

Comment 1 Andy Grover 2012-06-05 23:26:39 UTC
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".

Comment 2 Gris Ge 2012-06-11 07:57:49 UTC
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?

Comment 3 Andy Grover 2012-06-11 21:20:13 UTC
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.

Comment 4 Gris Ge 2012-06-12 02:01:26 UTC
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).

Comment 5 Gris Ge 2012-07-06 05:02:08 UTC
Keep this bug open for document update.

Comment 6 Gris Ge 2012-07-06 05:18:00 UTC
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

Comment 7 RHEL Program Management 2012-07-10 07:01:54 UTC
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.

Comment 8 RHEL Program Management 2012-07-10 23:11:10 UTC
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.

Comment 11 xhe@redhat.com 2017-11-08 06:49:16 UTC
Hi Maurizio,
Do you plan to fix this bug on 6.10?

Comment 12 xhe@redhat.com 2017-11-08 06:57:08 UTC
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

Comment 13 Jan Kurik 2017-12-06 11:41:53 UTC
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/