Brocade Fibre Channel Networking Community

Expand all | Collapse all

DiscoverLUN fails to see LUNs

  • 1.  DiscoverLUN fails to see LUNs

    Posted 09-26-2016 12:29 PM

    We are mapping 99 servers to their individual LUN over 8 paths, 792 paths total. Our software first creates 792 zones for each path. It then issues a single cfgadd for all those zones. It then adds 792 initiators over 32 CTCs in batches of 20 to stay under the commit limit of 25. Next it performs a discoverLUN and if it sees one it issues a LUN add (This is also done in batches of 20). We have performed this operation a couple times and it fails the discoverLUN at the same point each time. After it has committed 140 add LUNs the next batch of 20 discoverLUN fails after the 12th path, or the 152nd total discoverLUN. This process was then attempted on 99 different servers and it occured at the point, 152nd total discoverLUN.


    When we updated the zone/config for one of the failed luns, then all of the luns became discoverable after that, not just the one we updated.  This is interesting because the lun not being discoverable would be the same behavior we would expect if the zone config was not committed or enabled.


    Anyone seen this behavior before where a discoverLUN fails to see a LUN? 



    2 DCX switches, each with a FS-18 encryption

    FOS 7.4.0a


  • 2.  Re: DiscoverLUN fails to see LUNs

    Posted 09-26-2016 01:19 PM
    Automatic zonning it's difficult troubleshooting way.

    But partial discover fail often associated with scsi timeout in multipathing software. Another words discover take more times than scsi timeout limit.

    Which OS installed? Read the first driver's refference manual. I saw similar behavior in AIX partitions.

  • 3.  Re: DiscoverLUN fails to see LUNs

    Posted 09-27-2016 05:31 AM

    Hi Pavel, thanks for replying.


    This is the discoverLUN command on the encryption Crypto Container. The BES is not seeing the LUN when the example command below is run. It seems as though we are hitting some kind of bug or limitation. All of our servers only use SAN storage (no local storage) and remain powered off until their LUNs are mapped. They then boot off their LUN so if the discoverLUN on the CTC doesn't work then we can't add a LUN to the CTC and the servers have no storage to boot from.


    cryptocfg --discoverLUN ctc1



    Our automated process for mapping LUNs to servers has worked for years. What changed is that we upgraded to 7.4.0a and we changed from having a single path from server to LUN to having multipath (8 paths). Implementing multipath of course, increases the number of initiators & LUNs added to CTCs. Our software is successful mapping 57 servers, 8 paths per LUN, from each server. When we increase to 99 servers, we see the discoverLUN does not detect a LUN.


  • 4.  Re: DiscoverLUN fails to see LUNs

    Posted 09-27-2016 08:46 AM
    Hi, Gregory!
    May be this restriction?
    There is a maximum of 512 disk LUNs per Initiator in a container. With the introduction of Fabric
    OS 7.1.0, the maximum number of uncommitted configuration changes per disk LUN (or maximum
    paths to a LUN) is 512 transactions. This change in commit limit is applicable only when using BNA.
    The commit limit when using the CLI remains unchanged at 25.


  • 5.  Re: DiscoverLUN fails to see LUNs

    Posted 09-27-2016 09:12 AM

    It occured again today. This time under different conditions. A single LUN mapped encrypted to a single server over a single path.


    First, the LUN was successfully mapped to the server encrypted over a single path. Some data was copied to it and it was then unmapped. The LUN was then mapped again to the same server but after adding the initiator to the CTC the discoverLUN failed to show the LUN causing our software to error out.


    I logged into the switch CLI and tried issuing the discoverLUN myself but it still did not show the LUN. I removed the Initiator from the CTC and committed the change. I then added the Initiator back to the CTC, committed the change, and ran the discoverLUN which saw the LUN.


    So removing and adding the Initiator corrected the discoverLUN in this instance. Tho, this doesn't correct the issue of it failing in the first place.