It’s true, Allan is leaving VI.
Tag Archives: VW3
How to Collect DCNM and BNA Data via SMI-S Interface
OK, I need to come clean on one thing: this article isn’t about SMI-S per-se, but about connecting via CIM-XML. The thing is, “what is CIM-CML?” When a client connects to, let’s say, BNA, it can talk CIM-over-HTTP, CIM-over-HTTPS, or CIM-over-RMI. In hindsight, maybe I should have focused on RMI, but I had reasons. Had I titled this “…Data via CIM-XML over HTTP”, I would anticipate glazed eyes, and no real up-take on why this matters.
The trick is: it doesn’t matter a whole lot. …but it’s there if you need it, simply because I had it around.
We typically draw information from BNA (and alpha-quality in DCNM) by speaking directly to the underlying database, like this:
So normally, that’s a command such as:
java -jar vict.jar -N bnapsql://bna.example.com/
java -jar vict.jar -N dcnmsql://dcnm.example.com/
(again, needs QA)
These use the BNADatabase passwords, not the user’s password with which he is more familiar. These are typically hindered by ACL (the evil “pg_hba.conf”, all 4 of them).
The thing is, this method (in BNA) gets the data that isn’t available by SMI-S… err… CIM-XML. This gets the aliases that are not zone aliases. If you don’t recognize the difference, or remember “the McData way”, understand that some data isn’t available.
So there I was working on a DCNM Writer for a customer. It’s been taking way too long, and in order to test, I had added a DCNM CIM-XML client to the parsers. I needed something to bang on the DCNM and see what it had for when I try to push changes into it.
I needed this:
I decided to complete a functional BNA client (alpha), together with a DCNM client, and make those available to both vict.jar (VW3) and (VW4) vw4tools.jar via underlying FibreChannel-Parsers. They’re used like this:
java -jar vict.jar -N bnacql://bna.example.com/
(this one needs QA)
java -jar vict.jar -N dcnmcql://dcnm.example.com/
java -jar vw4tools.jar -N bnacql://bna.example.com/
(this one needs QA)
java -jar vw4tools.jar -N dcnmcql://dcnm.example.com/
The abbreviation for the protocol is BNA/DCNM, followed by CQL, the CIM Query Language, which is actually similar to SQL92 (Language, not Microsoft product). Microsoft has a variant for the WMI called WQL. If you like, you can be more explicit able the defaults:
java -jar vw4tools.jar -N dcnmcql://scott:T1ger@dcnm.example.com:5988/cimv2
Of course, you’d want a -o or -n to make use of the collected data, and you’ll see collected nicknames show up as NicknameParser counts (these data sources feed a text stream that is parsed by NicknameParser). vw4tools has full capability to –pattern itself into some upper-level entities, or just spit out fcports.
…and that’s the power of what I’ve done: the BNA and DCNM portions are merely small layers over the underlying capability. I could replace the vCenter collector with a CIM-XML client, or use that to interrogate various storage devices, but I assume VirtualWisdom4 Discovery will eventually do that for us in a much more Quality-check and code-reviewed and reliable manner.
As a reminder, the things I build are intended towards the installation timeframe, where a few hiccups are accepted so long as the task is completed. I don’t necessarily feel these tools would be used beyond installation day.
Version 1.0.73 – Collect Nicknames via CIM-XML CQL Client
This edit allows two additional “protocol” values: instead of just http, ftp, bnapsql, dcnmsql, and the formats listed on FibreChannel-Parsers docs, this adds:
- bnacql://user:pass@server:port/path to query a BNA server using CQL
- ie bnacql://bna.example.com/
- ie bnacql://scott:tiger@bna2.example.com:5988/cimv2
- ie dcnmcql://dcnm.example.com/
- ie dcnmcql://scott:tiger@dcnm.example.com:5988/brocade1
- ie dcnmcql://customer:pass@dcnm.example.com/
For example, I’ve been hammering away at it using a command like this:
java -jar vict.jar -N dcnmcql://admin:adminpass@192.168.1.130/ -n nick.csv
… and I would see that the collection extracted 3 DeviceAliases.
The DCNM CQL client draws out Device Aliases, but I haven’t found fcaliases yet.
The BNA CQL client will draw out Zone Aliases, but not Aliases of the non-zone-alias sort.
Why? I needed a CIM-XML client for some work I was doing, and I had the code loosely working so that I could use it to test the other real deliverable. Since I had a DCNM client already, I split the Cisco-specific stuff out, and slotted in a BNA client. The DCNM client (via dcnmcql) is working just fine, but I don’t have a test server to beat up with the BNA client. It works in theory?
How is this useful? Not a whole lot, since VW4 will use a protocol like these to collect information, but I’d like to point out something:
this doesn’t need a license
This would actually let a customer check “will VW4 see all of my aliases?” which — as Application Engineers and Deployment Techs know — is actually a fairly long pole in the circus tent of VW4 deployments.
Version 1.0.72 – Fix a Null Pointer Exception
This release is simply a bug fix: Chris Carlton gave the vict.jar a command that caused a parser to be not-sane; the resulting null propagated, and trashed out the entire parser. Unfortunately, the exception cascaded to the array of parsers, breaking isolation and tearing down all the parsers.
This would affect both vict.jar and vw4tools.jar as both share the underlying FibreChannel-Parsers
I need to create wrapping exception blocks to stop repeats of the cascade, but in the short-term this one symptom is resolved in this release. …with my apology.
Version 1.0.71 – SwappedNicknameParser
I created a specific instance of the NicknameParser as a convenience: I worked with a colleague on a limited environment wherein he could not run a “awk -f swap-1-2.awk” to swap columns, and wasn’t getting results from the parser. To be honest, it took us both too long to realize that the simple WWPN/Nickname order was swapped to Nickname/WWPN.
I hate being surprised by software when there’s a deadline; as well, I like to cater to jet-lagged Application Engineers and anyone who “just wants to get the gig done”.
This adds a NicknameParser as a --nickname=file.csv;WWN=1;Nickname=0
but avoids having to explain that. This situation is common enough, this addition just helps get it done with very little drawback.
FibreChannel-Parsers added the SwappedNicknameParser; vitools includes a test case to ensure that the fcparsers.jar picked up during the build includes the convince feature.
Version 1.0.54 – Version-Bump 3.7.0
Hey, Wow, I hadn’t bumped the internal version-check to 3.7.0.
So that’s done, and the PHC should no longer worry about the latest VW3 release when sanity-checking an environment.
Version 1.0.51- SubstituteWithSNICK fixed
I fixed a NullException in the -S function to vict.jar
The -S (Substitute with SNICKs) is similar to the -f (filterOut) as follows:
FilterOut (-f) removes all nicknames that are “predictable” or “provided” in VW3, and most likely provided by the VW3.x system to take the place of empty nicknames. Recall that VW3 will show an alias if available, an FCID is there’s no nickname, or a WWPN if no FCID is granted to a FLOGI. This means nicknamed devices show nicknames, but F-ports lacking nicknames show FCIDs, and ISLs (wherein no FCID is available) show WWPNs of the remote switch. FilterOut removes those predictable values, so that only the nicknames not appearing to be WWPN, the name “nickname (ISL)”, nor FCIDs (5-digit and 6-digit) are given. It can reproduce the original imported nicknames.
The risk, of course, is that bogus nicknames can be artificially elevated in status. The “provided” nicknames are overwritten by VW3 as new ones are available. A WWPN re-FLOGIs and gets a new FCID, that redefines the FCID-based nickname. The VW3 system will not overwrite a user-provided nickname, however.
What happens when the user imports a FCID-based nickname? The VW3 system will not overwrite it, so the wrong FCID is shown instead of the correct one. There’s no strong indication that this is occurring: VW3 doesn’t track whether a nickname is being conveyed or generated/provided. Additionally, “use Key Aliases” turns off ALL aliases, treating VW3-provided nicknames like user-provided nicknames.
FilterOut avoids this, and it’s as simple as using after a -nickname= collection:
VICT.BAT -N bna://bna.example.com/ -f -n nicknames.csv
java -jar vict.jar -N bna://bna.example.com/ -f -n nicknames.csv
SubstituteWithSNICKs (-S) takes this one more step:
- filter it out
- if there is a SuggestedNickname (SNICK) (see http://github.com/chickenandpork/wwndesc/), replace it with that
This allows the user to remove all FCID nicknames and replace them. Storage devices, SVCs, even some NPIVs (hey, vConnect and UCS, I’m looking at you) can be swapped in, identifying, for example, the Chassis (002a6a) of a UCS.
it’s just as simple as FilterOut:
VICT.BAT -N bna://bna.example.com/ -S -n nicknames.csv
java -jar vict.jar -N bna://bna.example.com/ -S -n nicknames.csv
or, verbosely:
VICT.BAT --nickname=bna://bna.example.com/ --suggestednicks --nicknameout=nicknames.csv
java -jar vict.jar --nickname=bna://bna.example.com/ --suggestednicks --nicknameout=nicknames.csv
Revision 677 – Additional Dupe WWPN Issue When Lacking fcalias
Another issue was discovered in that Cisco “show zones” command is giving results such as:
zone name z23_test44 vsan 300 pwwn 10:00:00:00:c9:12:34:56 [realalias] pwwn 10:00:00:00:c9:12:34:57 [otheralias]
Lacking the fcalias, this confused the Show Zone parser (Revision 657 – Cisco Show Zone), in a way slightly different than in Revision 674 – Dupe Alias in Show Zone. There’s no ambiguity between two nicknames or aliases, but the parser wasn’t picking up all possible pawn lines (i.e. reporting 10:00:00:00:c9:12:34:56,realalias
but not reporting 10:00:00:00:c9:12:34:57,otheralias
.
This was resolved by creating an additional parser with more code paths in the ShowZone2Parser to collect all subparts of a zone into the zone after the section is complete, and to collect all parts into each fcalias as a new fcalias was found or the zone is completed.
There’s still a few caveats to chase down, as noted on that class’s description.
A test case was added to this project to confirm the problem is resolved going forward.
Revision 674 – Dupe Alias in Cisco Show Zones
A problem was discovered in that Cisco “show zones” command is giving results such as:
zone name z23_test44 vsan 300 fcalias name testhost vsan 300 pwwn 10:00:00:00:c9:12:34:56 [realalias]
This confused the Show Zone parser (Revision 657 – Cisco Show Zone), plus it was ambiguous which name (“testhost” or “real alias”) should be used.
This was resolved in ShowZoneParser to use “realhost” silently; a test case was added to this project to confirm the problem is resolved going forward.
Revision 672 – OnCommand and DCNM Clients Migrated
In this revision, minor changes were done to move the OnCommand and DCNM client code outside of the non-public source base and into the public source base at OSMURLConnection.java and DCNMURLConnection.java. This allows for external audit of the code and may improve trust and reduce concern. This is very similar to the work done in Revision 670 – BNA Client Migrated
As with Revision 670, the project retains all the test cases involving this and other parsers, so functionality is verified retained, there should be very little change in behavior. The DCNM backend-database client remains beta-quality and requires further testing if a user is willing; the OnCommand client has been heavily tested.
The OSM or OCI backend-database client was added 14 months ago (Revision 516 – Added parsing of OnCommand Data for Nicknames); DCNM backend-database client was added 13 months ago Revision 541 – Added parsing of DCNM Data for Nicknames). The OnCommand client was altered to append a fabric name for a specific environment 11 months ago (Revision 578 – NetApp msosmsql Pseudo-Protocol Adds Fabric Suffix) but can be used to show how easily the output can be transformed.