Use LUN Nicknames in VirtualWisdom to Identify VLUN SymmDevice Names

awk, How to, LUN, Nickname, Symmetrix No Comments »

When some customers look at the output of our Hardware Probes such as the 8g FC8, and they’re confirming that all their Oracle transactions are meeting the SLA of 8ms, the LUNs they see are a bit unusual. They’re used to seeing LUNs such as LUN32, LUN33, but VirtualWisdom shows them LUNs like 17652, and they just don’t match up. This hinders the utility of the data, and may reduce the confidence they have in the data itself. When data drives decisions, we need accuracy and we need to be as easy to use as we can based on what we have available on the FC link.

The truth of the mismatch is that the devices involved actually convert the LUN numbers: where Virtual Wisdom shows you “17652″, that’s actually the LUN “on-the-wire”. The actual LUN in the SCSI frame is that large number, but vendor-specific tools convert it to manageable, familiar numbers — which can make the actual LUN appear “wrong”. Although it’s very simple to say “VirtualWisdom isn’t making the same conversion as your vendor-specific tools”, we’d rather be more helpful. When you have a problem on your SAN, “VirtualWisdom doesn’t support…” offers no help towards fixing the problem. Rather than “17652″, we’d rather tell you “Symm Device 1E2B”, which — for a very important customer of ours — is a comfortable middle-ground in identifiers and terms for the LUNs.

So how can we get a usable label on those LUNs? How do we do the lookups for you so that in an emergency, you have the details you need, already dereferenced?

As you’ve seen in the articles I’ve posted, I’m a Field Application Engineer for Virtual Instruments, and making this conversion — plus automating it — are the challenges I enjoy working on and sharing. This how-to article shares how to get SymmDevice aliases mapped onto LUNs as nicknames in a scriptable method. Let’s dive in:

Process Overview

For this process, our flow will look like the following:

In this diagram, the “sysinq” command is used to generate the “sysinq.txt” file; that part of the process is quite dependent on the tools available on your servers, hence shown dotted.


We at Virtual Instruments have witnessed this odd mismatch in LUNs for some time, and initially we just said “Subtract 0×4000″, but that didn’t work precisely. In another instance, we found two servers with a very similar number, so the informal rule became “subtract 17506″, but we later found that this rule was unusable outside that customer. Recently, in very detailed discussions, a customer found the logic that gets them to their LUN Nicknames, as follows:

The “sysinfo” file looks like this: (mocked-up example from testcases)

disk 1071 8/0/12/1/ sdisk CLAIMED DEVICE EMC SYMMETRIX
lunpath 1071 8/0/12/1/0.0x50060482d5123456.0x4392000000000000 eslpt CLAIMED LUN_PATH LUN path for disk6219
disk 1071 8/0/12/1/ sdisk CLAIMED DEVICE EMC SYMMETRIX
disk 1071 8/0/12/1/ sdisk CLAIMED DEVICE EMC SYMMETRIX
lunpath 1071 8/0/12/1/0.0x50060482d5123456.0x4392000000000000 eslpt CLAIMED LUN_PATH LUN path for disk6219
lunpath 1071 8/0/12/1/0.0x50060482d5123456.0x4392000000000000 online

The key part of this file is the line that says:

lunpath ...0x50060482d5123456.0x4392... disk6219

In this case, “50060482d5123456″ is the storage device’s WWN, and 0x4392 is the LUN (17298 in decimal) we detect as the actual LUN used in the SCSI exchange for disk6219.

The “syminq” file looks for a certain server like this: (again, mocked-up example from testcases)

/dev/rdisk/disk6219 R1 000190102037 5773 3701E8B000 2096640
/dev/rdsk/c23t1d2 R1 000190102037 5773 3701E8B000 2096640
/dev/rdsk/c43t1d2 R1 000190102037 5773 3701E8B000 2096640
/dev/rdsk/c133t14d5 R1 000190102037 5773 3701E8B000 2096640

The key part of this file is the line that says:

...disk6219 ...3701E8B...

That rdisk entry is as follows: (keep in mind, the content is replaced by bogus values: some common values may not align anymore)

  • /dev/rdisk/disk6219 is a local device node on the host
  • I’m not sure what “R1″ stands for
  • 000190102037 is the Symmetrix serial number
  • I’m not sure what “5773″ means (model number?)
  • 3701E8B008 breaks down as:
    • 37 — last two digits of serial 000190102037
    • 0 — not sure
    • 1E8B — the SymmDevice ID
    • 000 — Director port number
  • 2096640 (2^21 -512) means the LUN has capacity ~2TB

I don’t have official information, but it’s possible that 01E8B is actually “Symmetrix device 01E”, and “Director #8B”. 0x8b larger than 16 used to mean Processor B, but that seems a bit outdated now. The tools we use could easily give out 5-digit SymmDevice-XXXX values if we could confirm this numbering breakdown.

Essentially, the SysInfo2LUNNickname.awk script does the following:

  1. pre-loads a syminq file to provide “better” nicknames where possible
  2. parses the sysinfo to realize nicknames, substituting syminq results where possible
  3. Output the results as a new-style (VirtualWisdom v2.1 or later) nickname CSV

The resulting nicknames.csv has a series of lines such as:


As you can see, where there is a “better” match, “SymmDevice-1E8B” is used; otherwise, “diskXXXX” is still there. At this particular customer, “1E8B” is an example of a common name for their LUNs rather than the 17298 reported by VirtualInstruments or the 0×4392 reported in hex.

For exceptionally large syminq files, because gawk.exe is loading up a large associative array, memory usage may temporarily peak; this has been tested on 500k – 1MB text files without visible adverse effects, but hidden memory usage such as interpreters’ associative arrays and implicit memory-management is something to be aware of.

Running the Script

gawk.exe -v SYMINQ=syminq.txt -f SysInfo2LUNNickname.awk sysinfo.txt > nicknames.csv

It’s that simple. In order to improve re-use, I collected this logic as the AWK script because I’ve never had portability problems with AWK except for the UNIX/Windows CR/CRLF/LF text line-endings debate.

The script is non-interactive, but prints the results, so the script is typically run with the output redirected to a file. Running it is very quiet, as you’d expect:

gawk execution screencap showing LUN Nickname creation

Complete Example

A complete example is difficult for this how-to because the files used are scattered on each server; collecting the sysinfo, and the syminq output from each server may be the more difficult part. My test example looks like the following (I always recommend using full pathnames for tools):

@echo off
cd VirtualWisdomData

REM following is all on one line but split here for easier reading
-v SYMINQ=sandatasyminq01.txt
-f sandataSysInfo2LUNicknames.awk
sandatasysinfo > VirtualWisdomDataDeviceNicknamenicknames.csv

Similar to previous Nickname-generation/derivation tutorials, this process generates a single nicknames.csv file. You could append this result to any other generated file for which you already have an import schedule, or create a new one. In order to be as complete as possible, I’ve included an import schedule example that should be surprisingly similar to the others (and similarly brief: the User Guide has more detail regarding Schedules)

  1. Views Application, Setup tab: Views Application, Setup Tab
  2. “Schedules” page, roughly 5th item down: Views Application, Setup Tab, Schedules page
  3. Create a new Schedule, with the action “Import WWN Nicknames”: (or, if you prefer, “Import LUN Nicknames”) Views Application, Setup Tab, Nickname Import Schedule
  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:Nickname Import configuration, nicknames.csv

Use UDCs to Collect Devices by Name Pattern in VirtualWisdom

awk, How to, Nickname, UDC No Comments »

Virtually all SAN devices that are zoned for traffic have names (in fact, if you have nicknames/aliases in your zone files, then you can directly convert zone info to nicknames). VirtualWisdom’s filtering capabilities allow you to restrict a Dashboard, Report, or Alarm Policy Ruleset to a specific datacenter or business unit, but often creating those UDCs can be cumbersome.

A recent customer created UDCs with 192 values across three metric sets, allowing him to group data by specific servers, storage, and virtualizers automatically; this “how-to” is intended to show how you can do the same.

Process Overview

For this process, we need only a set of nicknames; the simpler old-format nickname file looks like:


(Notice: WWN first, no spaces, optional quotes for safety)

Generate UDC Values from Nickname Pattern

Our flow for this process or pipeline looks like the following diagram:
Flow of a UDC generated by pattern from Nicknames

The tool we use here is “awk”, or “awk.exe”, or “gawk.exe”; in Solaris, look for “nawk”. It’s on virtually every non-Windows system, Microsoft has a version in its tools for UNIX, or Google may help you find a copy. As well, UnxUtils has a version.

Awk is an interpreter, so needs a script or program, and for that, we use TransformUDC.awk which takes the following parameters:

parameter Meaning
COL What column in the CSV input is the Nickname? (default: 1)
NAMEFCX_LINK Name of the ProbeFCX::Link UDC
NAMEFCX_SCSIINIT Name of the ProbeFCX::SCSI UDC, matching Initiators only
NAMEFCX_SCSITARG Name of the ProbeFCX::SCSI UDC, matching Targets only
NAMESW Name of the ProbeSW::Link UDC (default: Transformed_UDC)
TRANSFORM Transform (basically the ‘s/x/y/g’ in a “sed -e ‘s/x/y/g’” command) (default: remove last two _sect_sect: DC_Serv1_fcs0_SW12P121 –> DC_Serv1)
UDCDEFAULT Default value for UDCs (default: Unknown)

A simple command such as the following will generate our results:

gawk.exe -f TransformUDC.awk Nicknames.csv

In our nickname file, the older format (first and second variant up to VW-3.1) gave us the nickname as the second parameter, so let’s tell the script that the nickname is in column #2:

gawk.exe -v COL=2 -f TransformUDC.awk Nicknames.csv

The problem is: how do we want the UDC values defined? If you’ve used “sed” or “awk” before, there’s a basic replacement term that looks like s/dog/cat/g or gsub("dog","cat",$0) … this part really depends on your nickname format, but looking above, we have nicknames that look like:


We see how, in this example, chopping off everything after the “_” gives names such as “Billing43″ and “DMX1927″. In see and awk, we would write: s/_.*$//g so we’ll use that as our transform. How can we test this?

Trim Quotation Marks

We could trim off the quotation marks around the second field using this: (“,” as field-separator, convert (“) to (), an empty replacement)

gawk -F, '{gsub(""","",$2); print; }' Nicknames.csv

… unfortunately, we need to use quotation marks for the script, and then we need a bunch of “” escape sequences, so it looks much more complex running it:

gawk.exe -F, "{gsub("\"","",$2); print; }" Nicknames.csv

… which looks like:

awk Transforms: Trim Quotations

Truncate All After “_”

Based on the example above, we can now test whether our transform (“s/._*$//g”, or gsub(“._*$”,”",…) ) gives us the results we want, such as (notice: “print $2″, so we’ll only see the second field):

gawk.exe -F, "{gsub("\"","",$2); gsub("_.*$","",$2); print $2; }" Nicknames.csv

… which looks like:
awk Transforms: Trim Quotations, Trim Nickname

This means our transform works, so let’s use it in the script:

gawk.exe -v TRANSFORM="s/_.*$//g" -v COL=2 -f TransformUDC.awk Nicknames.csv

Unfortunately, “4241″ is not worthwhile to us because it’s only one matching name, so let’s trim that one off by saying “minimum of 2 matching names per UDC value”:

gawk.exe -v MIN=2 -v TRANSFORM="s/_.*$//g" -v COL=2 -f TransformUDC.awk Nicknames.csv

Finally, What do we want to call the UDC? The tool always generates a ProbeSW::Link UDC, and if unnamed, defaults to “Transformed_UDC”. The Name of the UDC is limited to 32 characters, and values themselves to 24 characters; the name of the UDC becomes the name of the “metric” or context that we are generating. Suppose while working at XYZ Cheese and Dairy Distributors, we want a UDC called xyz-SW-BizUnit (we need to use “_” rather than “-”):

gawk.exe -v NAMESW="xyz_SW_BizUnit" -v MIN=2 -v TRANSFORM="s/_.*$//g" -v COL=2 -f TransformUDC.awk Nicknames.csv

Let’s run this with a redirection (“>”) to store the results to a file:

gawk.exe -v NAMESW="xyz_SW_BizUnit" -v MIN=2 -v TRANSFORM="s/_.*$//g" -v COL=2 -f TransformUDC.awk Nicknames.csv > VirtualWisdomDataUDCImportxyz-UDCs.udc

Running this as a command in cmd.exe is relatively quiet because this is a non-interactive command. It tends to look like the following:

gawk -f TransformUDC Nicknames.csv to xyz-UDC.udc

Importing this example, we see the following (you’ll note: the default has also been set using “-v UDCDEFAULT=Other”) :

Generated UDC values as viewed in VW Views

Schedule UDC Import

Creating the schedule is relatively straight-forward: although there is some strong guidance in the VirtualWisdom User Guide, a complete example would like like the following:

  1. Views Application, Setup tab: Views Application, Setup Tab
  2. “Schedules” page, roughly 5th item down: Views Application, Setup Tab, Schedules page
  3. Create a new Schedule, with the action “Import UDC configurations”: Import xyz-UDCs Schedule in Views
  4. …and configure it to use a new UDC Importing Configuration, as follows. NOTE we only use a local filename, all files are in the UDCImport directory of your VirtualWisdomData folder:Vies Application, Setup Tab, UDC Import Configuration (shortened)

The benefit here is that the UDC always replaces existing values without prompting. As well, after import, a UDC re-calculates values for both past summaries and new summaries. This allows you to “fix history” if your UDC is not quite correct the first time.

Convert Zone Info to Nicknames for VirtualWisdom

How to, Nickname, Zone No Comments »

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

Diagram of data-flow of nicknames from switches to VirtualWisdom

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, 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 D:VirtualWisdomDataDeviceNicknameFabricA.csv

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

For example:

screen cap of the DBToolScript -n run
(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.


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,, and a Brocade/zoneshow switch)

plink.exe -l scott -pw tiger zoneshow >

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

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

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.


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 > D:VirtualWisdomDataDeviceNicknameFabricA.csv

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

gawk.exe -f cisco-devicealias2wwncsv.awk > 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 "show device-alias database" >
plink.exe -l scott -pw tiger "show fcalias" >
plink.exe -l scott -pw tiger "zoneshow" >
plink.exe -l scott -pw tiger "alishow" >

gawk.exe -f brocade-alishow2wwncsv.awk > nicknames.csv
gawk.exe -f cisco-devicealias2wwncsv.awk >> nicknames.csv

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: Views Application, Setup Tab
  2. “Schedules” page, roughly 5th item down: Views Application, Setup Tab, Schedules page
  3. Create a new Schedule, with the action “Import WWN Nicknames”: Views Application, Setup Tab, Nickname Import Schedule
  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:Nickname Import configuration, nicknames.csv

Use UDCs to Group ISL Trunks or PortChannels

How to, samplecode, UDC No Comments »

I recently worked with a VirtualWisdom Administrator who wanted to group his ISL port utilization to match his ISL trunks, so we worked out a method of doing this, and I wanted to share it.  As a Field Application Engineer at Virtual Instruments, I tend to focus on these lower-level “how to” issues, working with users to achieve the data representation they need to make informed decisions in lieu of guesses and rule-of-thumb.

Initially, this administrator and I spoke of “trunks”, but between Brocade and Cisco terminology, these mean different things. The aggregations of ISLs into single logical units are “Trunking” in Brocade, but “Port Channels” in Cisco. Trunking E ports in Cisco is a different thing. I’ll use “Aggregate” as much as possible to refer to this in terminology as vendor-neutral as VirtualWisdom is.

We discussed why this Admin wanted to see more than just “the top 20″ values on a list of ISLs.  Diving deeper, this was because the top 24 entries are all the same aggregate: essentially, the first entire page is taken up by channels 1 and 2 of a a single aggregate ISL.  He wanted to skip beyond this to see the next 20 or 40 ISLs so he could see which ISLs were getting near 90% utilization.  So… why not combine these into a single filter or expression that matches the aggregate, and make sure that each aggregate uses only one row of this resulting table?

Additionally, one switch vender implements this aggregation of ISLs as balanced utilization across a collection of links between the same endpoints; conversely, another vendor implements this by overflowing one container, then moving to the next. In essence, an abstract aggregation that is has 60% Utilization may look like a collection of ports or links each with utilization 60%, or might look like 6 out of 10 links with Utilization 100%, and 4 of 10 with 0%.  That’s very difficult to separate in the data, and can obfuscate which ISL aggregations are approaching maximum desired load.

VirtualWisdom’s focus is on ports: what type, attached to what, etc.  Using Aliases or Nicknames, we can describe the endpoint, and in VirtualWisdom 3.0.0 and later, those ISL Nicknames are determined for us.  Unfortunately, these all have switch/blade/port, they’re too detailed. We cannot use that combination for a “group-by”expression to separate out the ISL aggregate.

VirtualWisdom is “too detailed” in this case: it wants to show all the ports individually.

A User-Defined Context, or UDC, is a metric with constant values applied using filter expressions. We often use these to automatically apply a logical grouping that better represents the real world implementation. One ISL aggregate between two switches A1 and A2 tends to encompass all E or TE ports on A1 connected to A2, and conversely, all A2 E or TE ports attached to switch A1.  That tends to make this one ISL unique from others.  We create a UDC in the SNMP/Link scope with values based on the “name of the switch” in an ISL: for example, in “SW12A44:3:1 ISL” as a link name, “SW12A44″ is the switch name.  ISLs between two switches share the same switch names, but are distinct by this same manner from ISLs to other switches. All we need is a UDC with values such as “SW12A44″ where “Attached Port Name MATCHES ^SW12A44:*”, and “SW12B44″ where “Attached Port Name MATCHES ^SW12B44:*”.

An example UDC would look like (Using terminology that’s a bit Brocade-leaning for this UDC because the Administrator favoured Brocade terminology) :

UDC to Group ISL Trunks

As you can see, grouping these ISL connects by “Probe Name”, “Channel”, and “TrunkChannel”, and filtering by “Attached ISL” would summarize traffic on all ISLs by the switches each connects, but aggregating bandwidth of all trunk members between each switch. Grouping by Channel continues to help us keep the directions separate so that a trunk loaded with 95% in one direction and 5% in the other shows “95%” and “5%” rather than “50%”.

You’ll notice, too, that we’ve added short-circuit to mark any non-ISL as a “NoTrunk”, the same as the default value. This avoids running the heavier “MATCHES” expression to evaluate ports that aren’t even ISLs. Your Portal server will thank you.

This logic assumes that all ISLs between two switches are in the same Aggregate; if you have any two switches with more than one distinct aggregation of ISLs, our logic no longer applies. One of our Analysts has seen ISLs grouped into multiple distinct aggregates even though they’re between the same switches, but it wasn’t the case in the discussion sponsoring the work I wanted to share.

Some customers have smaller SANs with a few dozen switches; others exceed 280 switches. This number of switches, and the various ISL possibilities between these, makes writing and maintaining a UDC with over 200 values very difficult and labour-intensive.  Because the user is effectively transferring config information from one format to another, accuracy risks can enter where users are transposing digits, or delayed in echoing the updated config information, or (more often) is simply not informed that any change needs to be echoed or copied. These risks are significant detriments to using this method.

To de-risk this implementation and help you try it out, we’ve created a script to convert a basic list of ISLs with nicknames into a UDC: while the blogging engine doesn’t let me upload this file, your VI Support and Services teams can help you get “ISL2TrunkChannelUDC.awk”, and a version of “awk” to run it. If your report with a Data View of “Table” is saved as a CSV with the AttachedPortName in the 4th column, you would run this script as:

awk -v COL=4 -f ISL2TrunkChannelUDC.awk 'Table-(summary).csv' > ISLAggregation.udc

(resulting UDC tested on version 3.0.2 and version 3.1.0 pre-release, incompatible before version 3.0.0)

I hope this helps you keep watch on your ISL utilization, and show the correct justification for adding ISLs to an aggregation, or balancing traffic to another less-used edge switch.

Keep those nicknames updated, and have a great holiday.

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in