Bug 828697 - Need documnet for fcoe-target-utils LUN Mapping. [NEEDINFO]
Need documnet for fcoe-target-utils LUN Mapping.
Status: ASSIGNED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: fcoe-target-utils (Show other bugs)
6.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Maurizio Lombardi
Storage QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-05 04:23 EDT by Gris Ge
Modified: 2017-11-08 01:57 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
xhe: needinfo? (mlombard)


Attachments (Terms of Use)

  None (edit)
Description Gris Ge 2012-06-05 04:23:16 EDT
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 19:26:39 EDT
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 03:57:49 EDT
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 17:20:13 EDT
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-11 22:01:26 EDT
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 01:02:08 EDT
Keep this bug open for document update.
Comment 6 Gris Ge 2012-07-06 01:18:00 EDT
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 Product and Program Management 2012-07-10 03:01:54 EDT
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 Product and Program Management 2012-07-10 19:11:10 EDT
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 01:49:16 EST
Hi Maurizio,
Do you plan to fix this bug on 6.10?
Comment 12 xhe@redhat.com 2017-11-08 01:57:08 EST
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

Note You need to log in before you can comment on or make changes to this bug.