Tech Notes

VirtualWisdom uses “Nicknames” or “Aliases” to give human-readable names to attached SAN devices, reducing the time to locate a problem device, but also to help group devices logically as being the same server or storage, and into business units for SLAs and escalation of issues.

We know that Nickname management can be a hassle, but the obvious gains make it worthwhile, so some of our work in Services is helping customers draw this data from existing repositories such as fabric Zoning information. Maintaining aliases in your zones, then converting those to nicknames, means that you only need to maintain one repository of names.

This “How-to” article is targeted at showing how to do this in common environments. As a VI Application Engineer, my content on this feed tends to be more of a lower-level “how to” in nature. This content has been in our internal self-help content, but may be difficult to find.

Collection, then Conversion

The general process tends to be collecting the data, then converting to a compatible format for import. Let’s focus first on Collection, which tends to be a script running at scheduled times during the day or week.

Scripting under Schedule

This tends to be done as a batch file that is triggered through a scheduler such as the Windows Scheduler running a BAT file, or a UNIX-like OS running a shell script from cron or as a passive check under tools such as Icinga.

Where fabric-wide data is used, only one switch per fabric needs be queried. I tend to use the least-busy switch to avoid adding any load to Core switches or other busy switches.

Will DBTools Work for You?
The easiest method if you have small switches is to use Program FilesVirtual InstrumentsVirtualWisdomUnSupportedDBToolsDBTools.exe tool, but running it as a batch command. This tool will connect to the switch using SSH, query the information, and convert it to the right format for import. In essence, the collection and conversion is a single step. For example, using the example username “scott”, password “tiger”, switch IP 192.168.0.1, to a file FabricA.csv in the import directory:

Brocade “alishow”: (the command is all on one line)
DBToolScript.bat -n -st brocade -u scott -p tiger -ip 192.168.0.1 D:VirtualWisdomDataDeviceNicknameFabricA.csv

Cisco “fcalias”:
DBToolScript.bat -n -st cisco -u scott -p tiger -ip 192.168.0.1 D:VirtualWisdomDataDeviceNicknameFabricA.csv

For example:

(In this example, my demo server has the database on the C: drive; this is not the recommended config for production servers! Also, notice how the DBToolScript cannot open a log file — running this command in your VirtualWisdomData directory will allow it to write a log to .LogDBToolLog )

Putting commands such as this into a batch file running daily via Windows Scheduler, and configuring a scheduled Import via the VirtualWisdom Scheduler, your job is complete!

The DBTools command doesn’t understand all possible nickname sources, and may have problems on some switches; if this method doesn’t work for you, then we resort to the two-stage process. This less-polished method is a bit more versatile, but isn’t as pretty. Once configured, though, it tends to work reliably.

Collection

The more manual collection can be done from four different sources:

1. Brocade Switch using “zoneshow”
2. Brocade Switch using “alishow”
3. Cisco Switch using “show device-alias database”
4. Cisco Switch using “show fcalias”

Collection requires non-interactive SSH tools such as plink.exe available from the makers of Putty; google should help you find it, but if you cannot, VI can help redirect you. The general command is:

plink.exe -l username -pw password IP.IP.IP.IP "command" > intermediate.file

For example: (using scott, tiger, 192.168.0.1, and a Brocade/zoneshow switch)

plink.exe -l scott -pw tiger 192.168.0.1 zoneshow > sw-192.168.0.1.zone

… and a Cisco/”show device-alias database” at 192.168.0.3:

plink.exe -l scott -pw tiger 192.168.0.3 "show device-alias database" > sw-192.168.0.3.cisco

These commands give no output when they run, except the first time: the plink.exe command wants you to accept a key to later ensure you are not vulnerable to a man-in-the-middle attack, which looks like the following: (accept the key once, later you won’t be asked unless it changes)

Again, you only need to collect zoning information or fabric-wide alias information from one switch per zone. With a unique filename per fabric, you’re ready to convert these files.

Conversion

Brocade and Cisco tend to use consistent formats for their outputs, but they are in text format. Most times, the two scripts work for this. These are scripts for the “awk” tool, which can be extracted from the UnxUtils project, or using Microsoft’s tools for UNIX. Either method gives you a “awk.exe” or a “gawk.exe”, which will execute these scripts:

1. brocade-alishow2wwncsv.awk
2. cisco-devicealias2wwncsv.awk

Conversion of a Brocade zonecfg or alishow is done as:

gawk.exe -f brocade-alishow2wwncsv.awk sw-192.168.0.1.zone > D:VirtualWisdomDataDeviceNicknameFabricA.csv

Whereas conversion of a Cisco device-alias database or fcalias is done as:

gawk.exe -f cisco-devicealias2wwncsv.awk sw-192.168.0.3.cisco > D:VirtualWisdomDataDeviceNicknameFabricB.csv

Note: these runs are redirecting output to files, so these commands give no visible output to the cmd.exe screen except in the case of errors.

Complete Example

A complete example of collection and conversion may look like the following code. Be aware, we tend to recommend using full pathnames (i.e. C:Program Filessomethingelseplink.exe) to ensure the commands are found regardless %PATH% variable and working directory. This example is simplified to be more readable but does run as-is given the right environment and working directory.

@echo off

plink.exe -l scott -pw tiger 192.168.0.1 "show device-alias database" > sw-192.168.0.1.cisco
plink.exe -l scott -pw tiger 192.168.0.2 "show fcalias" > sw-192.168.0.2.cisco
plink.exe -l scott -pw tiger 192.168.0.3 "zoneshow" > sw-192.168.0.3.zone
plink.exe -l scott -pw tiger 192.168.0.4 "alishow" > sw-192.168.0.4.zone

This example generates a single file; the configuration to import this one file is as follows (briefly shown here because the User Guide has more detail regarding Schedules):

1. Views Application, Setup tab:
2. “Schedules” page, roughly 5th item down:
3. Create a new Schedule, with the action “Import WWN Nicknames”:
4. …and configure it to use a new WWN Importing Configuration, as follows. NOTE we only use a local filename, all files are in the DeviceNickname directory of your VirtualWisdomData folder: