Version 1.0.92 – vw4tool.bat repaired

Don pointed out that the vw4tool.bat was not working. It’s been resolved.

There was an edit in version 1.0.75 which quoted convenience BAT files for robustness. Unfortunately, this caused the conversion of vic.bat file into vw4tool.bat file to fail, so every vw4tool.bat was an exact copy of vict.bat.

The conversion is fixed, and vw4tool.bat should work as intended.

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:

wpg_div_wp_graphviz_1

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:

wpg_div_wp_graphviz_2

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
  • dcnmcql://user:pass@server:port/path to query a DCNM server using CQL
    • 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.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.56 – Host-Munging Aggregation Patterns

vw4tools added host-munging to improve chances of pattern-based aggregation. This allows a derived hostname that’s slightly different than the hosts (to allow for enforced consistency) or to allow for some flexibility in the hostnames and entities.

This was created specifically for a situation where a customer had lowercase aliases for the A fabric, uppercase for the B fabric. Although this seems quite simple and straightforward, “A” and “a” are different letters, so the collection of SERVER44_HBA0 and server44_hba1 is much more difficult. The only host-munging enabled currently is:

–munge=host:touppercase

for example:  (patterns command line options edited out for clarity)

java -jar vw4tools.jar -N (source) --munge=host:touppercase -oresult.json

or:

java -cp vict.jar org.smallfoot.vw4.VirtualWisdom4ClientTool -N (source) -M host:touppercase -o result.json

The different might be better explained as OrderedTuples Output:

java -jar vw4tools.jar -N (source) -oOrderedTuples.csv
SERVER44,host,10000000c9123456,SERVER44_HBA0
server44,host,10000000c9123456,server44_hba1

This gives:

  • (host) SERVER44
    • (hba) SERVER44_HBA0
  • (host) server44
    • (hba) server44_hba1

java -jar vw4tools.jar -N (source) -M host:touppercase -oOrderedTuples.csv
SERVER44,host,10000000c9123456,SERVER44_HBA0
SERVER44,host,10000000c9123456,server44_hba1

This gives:

  • (host) SERVER44
    • (hba) SERVER44_HBA0
    • (hba) server44_hba1

You’ll see that the second line of OrderedTuples has an uppercase parent entity. The first non-munge result shows two hosts, each of which has one HBA; the second example shows one (uppercase) host that contains two HBAs.

This matches the user’s request for all host entities to be the uppercase version of the upper-/lower-/mixed-case HBA alias or storage alias.

To ensure that vw4tools includes this fix, vitools adds the testcase to confirm that behavior is in the release includes/merged into vitools.

Version 1.0.40 – Confirm that Duplicate WWPNs Are Caught

In VirtualWisdom4 release 4.0.2, it was noticed that the JSON Validation before import does not trap duplicate WWPNs. Unfortunately, this was exasperated by one customer who had multiple duplicate entries in their CSV WWPN/alias maps that were previously routinely imported into VW3.

VirtualWisdom4 may still be vulnerable, so the NicknameParser now independently discards duplicate WWPNs; otter parsers currently may not.

This release confirms that the fibrechannel-parsers inbuilt to the vitools-1.0.40 jar file include this fix.

Version 1.0.39 – Confirm 4.0.2-based fcport Entities

in fibrechannel-parsers-0.3-121, the VW4 release 4.0.2 feature of fcport entity import was added. An FCPort acts as either HBA ports or Storage Ports when using Entity Creation Utility to create entities: the selection list for Host includes both HBA Port and fcports, for example.

In order to confirm that we always have a fcparsers version that includes this fix, a check case was added to confirm functionality, or fail if absent.

vitools-1.0.39 should always include this feature in the in-packed parser

Revision 666 – vw4tools.jar, vw4tool.bat, more parameters, and DeviceAliasParser

This revision was a rollup of a few updates, as follows:

vw4tools.jar and vw4tool.bat allow a basic windows user to locate and run their JRE against the vw4tools.jar file to non-interactively execute a function. This is very similar to the way vict.bat works, except that vw4tools.jar is rolled into vict.jar so both are available in the same package. vw4tool.bat does the right thing.

In order to allow more command line parameters, the convenience BAT files have swapped %# to %* for parameters. If you never ran into this, it’s no problem 🙂

DeviceAliasParser now ignores newlines; this was done in the FibreChannel-Parsers project externally, but testcases were corrected to confirm the behavior.

Revision 664 – Sync VW4 Content

The NW content is still synchronizing, as well as VW3 of course, but VW4 hasn’t been synching. That’s been added to the FTP server to push content to the EU staging, and provide a VW4 directory as requested by Stu Heron.

It’s great when I can rely on good friends to catch my oversight 🙂

It should now be present when you sync