Expanded the option “-w” from Suggested Nicknames for Known WWN Patterns to vict.jar such that vict.jar -w 2100000b08123450 shows “Axiom-12345-c0p0” giving suggested nicknames to (Oracle) Pillar Axiom (SLM). This WWN Descriptor is not very precise, but is empirically-based. Additional WWPN samples would help guide a better, more precise solution.
Tag Archives: VICT
Revision 560 – move FixNicknameHistory to VIFT
Per the conversation at SKO, the “–fixnicknamehistory” is the only art of VIClientTool (vict) that is a writeable action; otherwise, vict is read-only. In order to be sure that vict cannot hurt the database, the writeable portion of vict is moved back into the VIFieldTool (vift). vift is never left with a customer.
Revision 555 – Suggested Nicknames for Known VMAX WWN Patterns
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
Revision 554 – Suggested Nicknames for Known Clariion WWN Patterns
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/
Revision 552 – Suggested Nicknames for SVCs
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”
Revision 551 – Suggested Nicknames for Known WWN Patterns
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.
Revision 541 – Added Parsing of DCNM Data for Nicknames
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”.
Revision 540 – Fix OSMSQL Access
Fixed the access parameters for OnCommand Service Manager osmsql:// nickname source added in r516 and r525 based on Patrick’s info
Revision 536 – FixNickNameHistory for Database Back-Edits
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.
Revision 527 – Improved FileSystem Layout Detection
internal: the detection of filesystem layout and file relative locations was all twisted, and was flakey. So I’m ripping it out. It’s mostly refactored, but in order to leverage it sooner, there are currently both methods active. The flakey one will finish dying very soon, but in the meantime, only most of the code benefits from this structure change rather than all of it.
The way I’m doing it now is a straight Booch-ian method of taking multiple objects and using them to encapsulate the logic. They are interchangeable. The most applicable will be chosen by — you guessed it — voting. Whichever one looks most likely will be used. This allows me to abstract off discovery of pathnames and locations as they change from live server, PortalLogs, and database backup without huge changes in code and whackloads of if/else loops.
The behavior I wanted to leverage more quickly is the reading of summarymon log to check performance at the database insertion side.