In revision 558, I added a logic to PHC that exercises the “-w” from Revision 555: VMax Nickname Suggestion back to Suggested Nicknames framework so that for missing nicknames, a phc-Nicknames.csv file attempts ot provide suggested nicknames for the WWNs of missing nicknames that it understands.
In short, PHC now provides suggestions for missing nicknames, making it possible to have nicknames for hosts the customer may not even be aware are visible by the VW Platform.
Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 50000972081349AD shows “VMax-HK192601234-12gB” per https://community.emc.com/thread/118881
Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 5006016012345678 shows “CL-12345678-SPA0” per http://blog.fosketts.net/toolbox/emc-symmetrix-wwn-calculator/
Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar, expanding on the Symmetrix name pattern by adding recognition of SVC nodes. For example, vict.jar -w 5005076801234567 shows “SVC45_Node67_Port2”
In deployments, very often customers zone their storage based only on a zone-name and WWPN members. Typically this causes a need for the Zone-Vote Algorithm to be used, but that’s an approximation that requires the user to be consistent in Zone names, consistent in zone membership (ie anywhere one FA or HBA is used for an entity, all the others need to be used at the same time).
There are some cases where the WWN is entirely predictable; in such cases, the option “-w” to vict.jar (such as vict.jar -w 50060482B82F9654) shows a suggested nickname or alias such as “Symm-182500953-05bA” (per http://www.emcstorageinfo.com/2007/08/how-to-decode-symmetrix-world-wide.html) which can be leveraged to provide for missing nicknames.
Where possible, PHC.jar avoids simple things such as forgetting to set the LinkNames-From-Nicknames setting in Views::Setup::FabricManagement.
Not running the PHC.jar both skips the FAE’s Deployment Checklist, and risks the issues that the PHC checks for.
In this case, the FAE didn’t run the PHC, didn’t set the LinkNames-from-Nicknames, and the links don’t reflect the NPIV names. This is a serious problem in Analysis which is why Stuart Bridger asked for this to be added.
The input to this filter is a list of links and names (the script itself includes a viwc.jar sample). The result is a filter which can be used to ignore the NPIV ports in ProbeSW.
In revision 541, the basic capability to ask a DCNM service for the Nickname/WWPN mapping has been started. This has the potential to reuse the information entered into DCNM rather than re-entering manually, and avoid pulling zonefiles from each zone for parsing using a –nickname=file:// or –nickname=http:// method. As well, in situations where aliases are not used, we can collect the port labels or private aliases that DCNM may not share down to the switch.
This method is only initially defined, but requires a bit more work.
The same parser logic is used as was added for OnCommand in OnCommand Query and for BNA in BNA Query. Like the BNA and OnCommand work, the DCNM query simply reformats a query and sends it through the array of parsers to vote upon:
java -jar vict.jar --nickname=dcnmsql://user:pass@server:port/ --nicknameout=\VirtualWisdomData\DeviceNickname\nicknames.csv
Default user/pass should be accurate but need additional testing to confirm. Like the BNA parser, this method hits the underlying database directly, so it needs (firewalls/filters) direct access to the server, and is vulnerable to schema changes. Schema is based on 5.2 documentation.
In the meantime, cisco-shows2wwncsv.awk is also provided to build portlabel nicknames as import CSVs; this awk file needs two “show” commands on every switch. NOTE: every switch, not just every fabric, and it needs to see the output of “show flogi database” before it sees “show interface description”.
Fixed the access parameters for OnCommand Service Manager osmsql:// nickname source added in r516 and r525 based on Patrick’s info
In Revision 536, I implemented “–fixnicknamehistory” which applies any loaded nicknames (for example, those gained using OnCommand Extraction, those Parsed from Cisco Zones, or those extracted from BNA) to the underlying Portal Server database retroactively.
So long as the Portal Service is shut down, this can be done on a customer’s live server, but it’s more useful in analysis where nicknames arrived late yet the analyst cannot wait another week or so for nickname-ful summaries to be collected.
Every customer is different, and their nicknames of zone titles is no exception. There is no clear consistency in zone names which can then lead near-consistently to Attached Device Names. Nearly.
Zone-Vote Algorithm is always an assumption-lead guess. It poses only a slim chance of being 100% accurate.
In cases where the target in a zone title starts with the same prefix, this Stage-2 of the process can help narrow it down. I added Vote02-ZoneSplit2onTargetPrefix.awk to split zone names based on the prefix of the target device (for example if all targets start with STOR*)