From sysmgr 2.x through to the new versions on Windholes, Linux and OSX do not display all of our volumes. It seems to pick random volumes to not display. The array we are having the most trouble with has around 400 volumes per head (7 mode classic cluster and in the neighborhood of 2000 LUNs per however we have not noticed it not displaying LUNs). It will show the LUNs for volumes that don't show in the volume list but won't allow LUN creation for the volumes that you can't see in the volume list...was that clear as mud or what?! ^_^
Anyway it has progressed past "merely irritating" to "exceedingly annoying" and we would like a fix of some config advice?
NEW INFO: The GUI will not display more than 246 volumes.
NEW QUESTION: Is there a limit on the number of volumes or is there some memory constraint related to volumes name lengths that plays into this. Quite a few of the volumes have very long names due to the fact that this is secondary storage (test/dev mirror from production) and we have lots of clones and some clones of clones. Another question: I have noticed on at least one occasion that we could not see any clone of a clone volumes is there some limitation there as well? We try not to have multilevel clones but unfortunately what is best (reasonable) practice and what the customer wants are often at odds.
****** Need to add that once it decides which volumes to ignore it continues to not display those specific volumes. This is not the same between installations. A separate installation on a different machine will often choose different volumes to ignore.
I am not aware of any bugs that describe this behavior. I recommend that you open a support case and upload an OCSM support bundle collected just after navigating to the volume tab for an affected controller. You might increase the logging level for OCSM prior to navigating to the volume page to increase the chances that the cause will be found from that one log set.
To do that follow these steps:
1) Tools -> Options
2) Log Level --> DEBUG
3) Save and Close
4) Generate the error/failure condition (i.e. navigate to the volume page and allow it to load)
5) Set the log level back to INFO
6) Collect a support bundle or the logs from the System Manager installation path.
7) Attach the support bundle to your support case along with details regarding the controller used to generate the behavior.