EMC VMAX driver not using look up service for auto zoning

[Xing Yang]

The VMAX FC driver didn't use the look up service for auto zoning. Instead it built initiator target map itself. However, that requires the initiator to log into the fabric before zoning in order to find out target WWNs.

This patch is to use the look up service to find out valid initiator target WWNs and use that to build initiator target map. With this fix, the initiator is no longer required to log into the fabric ahead of time.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/127141

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/127141
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=8707458a98bd1e4059939325659a7290757d972f
Submitter: Jenkins
Branch: master

commit 8707458a98bd1e4059939325659a7290757d972f
Author: Xing Yang <email address hidden>
Date: Thu Oct 9 01:26:28 2014 -0400

    Use look up service for auto zoning

    The VMAX FC driver didn't use the look up service for auto zoning.
    Instead it built initiator target map itself. However, that
    requires the initiator to log into the fabric before zoning
    in order to find out target WWNs.

    This patch is to use the look up service to find out valid initiator
    target WWNS and use that to build initiator target map. With this fix,
    the initiator is no longer required to log into the fabric ahead of time.

    Change-Id: I76e1a8a2e7d4230b851b763f7d13dd1489b69364
    Closes-Bug: #1379156

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/131886

[Xing Yang (xing-yang)]

Without using the lookup service, the initiator needs to log into the fabric before zoning in order to find out target WWNs. This is a manual step and defeats the purpose of auto zoning. This also requires the default mode on the Brocade switch to be changed manually from "no access" to "all access" which has security implications.

[Carl Pecinovsky (csky)]

Xing,
I have reviewed the patch and tested it in our environment. The changes that add new utility methods and make use of them seem good and more correct than what was there before. However, I ran into two major issues:

(1) Our NPIV attach request did not just have a problem with auto-zoning...it failed much earlier than that when the Initiator Group needed to be created. That failure still happens. Here is a snippet of the logging:

2015-01-08 11:59:17.237 12858 DEBUG cinder.volume.drivers.emc.emc_vmax_masking [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] The found hardware IDs are : [] _get_storage_hardware_id_instance_names /usr/lib/python2.6/site-packages/cinder/volume/drivers/emc/emc_vmax_masking.py:540
2015-01-08 11:59:17.238 12858 ERROR cinder.volume.drivers.emc.emc_vmax_masking [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] Initiator Name(s) [u'c0507606a32c0656', u'c0507606a32c0657', u'c0507606a32c0654', u'c0507606a32c0655'] are not on array SYMMETRIX+000198700498
2015-01-08 11:59:17.239 12858 ERROR cinder.volume.drivers.emc.emc_vmax_masking [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] Cannot create or find an initiator group with name OS-csky_npiv5-05123912-00000005-F-IG

The VMAX does not know about the NPIV initiator wwpns. For other storage devices we support, we basically do operations that tell the backend, "Here are the initiator WWPNs. You don't know about them yet, so please add them to your database and mask them in for volume XX access." But for VMAX, the cinder driver flow raises the above exception when it cannot locate the WWPNs in the VMAX/ECOM database.

(2) It is unclear to me how the lookup service would know about the initiator WWPNs either. The defect description says "With this fix, the initiator is no longer required to log into the fabric ahead of time." I tried moving the lookup service call to code prior to the common.initialize_connection() processing. The logging shows that it does not know about the initiator WWPNs:

2015-01-08 11:57:47.733 12858 DEBUG cinder.zonemanager.drivers.brocade.brcd_fc_san_lookup_service [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] No initiators are in the nameserver for SAN a get_device_mapping_from_network /usr/lib/python2.6/site-packages/cinder/zonemanager/drivers/brocade/brcd_fc_san_lookup_service.py:180
2015-01-08 11:57:47.734 12858 DEBUG cinder.zonemanager.drivers.brocade.brcd_fc_san_lookup_service [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] Device map for SAN context: {'a': {'target_port_wwn_list': ['50000973f007c944', '50000973f007c905', '50000973f007c985', '50000973f007c945'], 'initiator_port_wwn_list': []}} get_device_mapping_from_network /usr/lib/python2.6/site-packages/cinder/zonemanager/drivers/brocade/brcd_fc_san_lookup_service.py:187

In my case, I only have one fabric "a", and the flow seems to be what I would expect - none of the four initiators are in the nameserver because the switch doesn't know about them since they aren't yet logged into the fabric.

Am I missing som...

[Xing Yang (xing-yang)]

Hi Carl,

We have not tested with NPIV. So I'll have to defer the answer until we get more information on that. NPIV support is in our plan. Will keep you updated. Thanks.