Fibre Channel (SAN)

Reply
New Contributor
Posts: 3
Registered: ‎10-25-2013

DiscoverLUN fails to see LUNs

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? 

 

Environment:

2 DCX switches, each with a FS-18 encryption

FOS 7.4.0a

Contributor
Posts: 66
Registered: ‎12-24-2015

Re: DiscoverLUN fails to see LUNs

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.
New Contributor
Posts: 3
Registered: ‎10-25-2013

Re: DiscoverLUN fails to see LUNs

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.

Contributor
Posts: 66
Registered: ‎12-24-2015

Re: DiscoverLUN fails to see LUNs

Hi, Gregory!
May be this restriction?
 
NOTE
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.
New Contributor
Posts: 3
Registered: ‎10-25-2013

Re: DiscoverLUN fails to see LUNs

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.

Join the Community

Get quick and easy access to valuable resource designed to help you manage your Brocade Network.

vADC is now Pulse Secure
Download FREE NVMe eBook