On 05/14/2015 10:09 PM, Nicholas A. Bellinger wrote:
Hi Andy & Co,
On Wed, 2015-05-13 at 12:13 -0700, Andy Grover wrote:
On 05/13/2015 12:48 AM, Tomasz Charoński wrote:
Dear Andy Grover, targetcli-fb Developers,
firstly, I'd like to thank you for your contribution in targetcli and
related libraries developing. I am writing to you to ask, if there it is
possible to add to targetcli qla2xxx_npiv support. I have been studying
this for 2 days now and it's hard to create NPIV targets manually.
Hi Tomasz!
I would hope we could add this and make it easier. I think some
challenges will be I don't have hardware to develop on, at least not
full-time, and also NPIV is a feature not represented in targetcli
before now. Some thought on how best to present it will be needed, see
below.
To create NPIV WWN using qla2xxx you need:
1. Create FC host using vport_create:
echo '1111222233334444:5555666677778888' >
/sys/class/fc_host/host5/vport_create
After this new /sys/class/fc_host/hostX will appear, but NPIV WWN is not
discovered at FC switch yet.
2. Create the path:
/sys/kernel/config/target/qla2xxx_npiv/21:00:00:xx:xx:xx:xx:11@5555666677778888:1111222233334444
where "21:00:00:xx:xx:xx:xx:11" is physical WWN taken from port_name
(sed needed).
Even though qla2xxx and qla2xxx_npiv are not represented hierarchically
in configfs (they're peers) I'm wondering if that's not actually a
mistake, and preferable to present differently in targetcli. It might be
clearer to show it hierarchically -- create an "npivs" node:
qla2xxx
o- 20:00:00:00:00:00:00:55
o- acls
o- luns
o- npivs
in which "npivs/ create 5555666677778888 npiv_wwnn=1111222233334444"
would actually jump over to the qla2xxx_npiv configfs dir and set stuff up.
and then that would have its own "acls" and "luns" nodes too:
qla2xxx
o- 20:00:00:00:00:00:00:55
o- acls
o- luns
o- npivs
o- 5555666677778888
o- acls
o- luns
**OR**
the phys wwpn node (e.g. "20:00..") could have a create_npiv command, e.g.:
00:55>/ create_npiv 5555666677778888 npiv_wwnn=1111222233334444"
leading to:
qla2xxx
o- 20:00:00:00:00:00:00:55
o- acls
o- luns
qla2xxx_npiv
o- 5555666677778888 [parent: 20:00:00:00:00:00:00:55]
o- acls
o- luns
my thoughts are to prefer the first way.
I like the second approach along with a extra [npiv] bit for the parent
endpoint who has NPIV endpoints enabled.
Also, auto-creating the parent if none already exists is helpful too.
Attempting to delete a parent endpoint with active NPIV endpoints should
fail, and is not allowed at se_tpg->tpg_group.cg_item level.
To me, both of these feature requests suggest NPIV endpoints should be
defined under the parent endpoint, to naturally model that dependency.
Are there reasons I'm not seeing to prefer the second approach beyond
that's what qla2xxx (and maybe others) have implemented? I'm ok with
either approach, it's just helpful for me to know if there are reasons
rtslib should attempt to follow configfs's layout, or if there's a more
natural API it can present to its users.
It would be more work for the
way tcm_qla2xxx implements NPIV but assuming LIO gets more FC fabrics in
the future, I'm not sure we'd want them to do npiv like qla2xxx did.
You'll still need to take a parent configfs dependency for lpfc target
mode.
Proper handling of lpfc target mode is a good reason to prioritize
getting it in the upstream kernel. Sebastian Herbszt posted a patch for
this on April 12, should we be making more of an effort to review that
for inclusion?
Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
