Zoning_info script to follow the vScsi mapped LUNs

If you are using NPIV across your environments then you don't have to bother with the question - which LUN is zoned to which server(s).

However, there are still a lot of places where the admins are still using the old-fashioned vscsi LUN allocations from the VIO servers.

The benefit of that is of course that you do not have to install any additional driver to the AIX clients, because the standard MPIO support is part of the basic installation, but on the flip side, it is harder to track exactly which LUN is mapped to which clients, especially if you are working with redundant Virtual I/O servers (In my view you should) or probably HA clusters.

The challenge is of course the fact that you have to map those LUNs manually to the clients (in a redundant way) and manage the mappings time to time (across new LUN allocations, server decommissions, new server builds, and stuffs like that) without missing any one.

In the top of that, if you have to do this with (let's say) 500-1000 LUNs (or more) this could easily become a nightmare after a few years.

That is the reason why I created a script to gather all LUN zoning and mapping details from the VIO servers using a central server and to check if there is anything odd around the zoning or the mapping, while using as less dependencies as it can.

Script is available here:

Download Script
Because of that the current implementation relies only on HMC(s). The reasons are the following:

- Some VIO servers have no external communication paths which could be reachable from a central server
- The HMC can detect all VIO installations inside a box
- The HMC can execute VIO related commands via the viosvrcmd command (via an RMC connection, which should be available for DLPAR operations)
- 1 HMC can manage multiple VIO servers, so it does not necessary to create communication paths between the central server and the VIOs (via SSH like example)
- Root access is not mandatory at all (assuming that you have an other ID which can communicate with the HMCs via SSH keys)

The implemented functions are the following:

# zoning_info.sh
Usage:
zoning_info.sh -make    : Gather all the necessary details from the HMC(s) managed VIO Server(s)
zoning_info.sh -all     : Check all LUNs
zoning_info.sh -free    : List the spare LUNs
zoning_info.sh LUN1,LUN2        : Check the specific LUN_ID(s) (separated by ',' )

The first step should be to create a cache via the '-make' command. As part of that the script will try to connect to each listed HMC(s), check the managed boxes, and the installed VIO servers, and all the zoned LUNs for each.

Once it's finished, you can query all, only one, or multiple LUNs (using their LUNIDs, separated by a comma).
In case there is anything odd around the zoning or the mapping, the script will report it.

Here are a few examples:

600507920190817B8800000000000178 (32 GB) is zoned to:
vio1 (hdisk26), assigned to a NON-ACTIVE partition (in box ZEUS) via vhost3 as lpar3_data01
vio2 (hdisk26), assigned to a NON-ACTIVE partition (in box ZEUS) via vhost3 as lpar3_data01
vio3 (hdisk48), assigned to GAIA_lpar6 /Running/ (in box GAIA) via vhost6 as lpar6_data03
WARNING - This LUN is associated for one or more inactive partitions.

600507920190817B88000000000001B3 (64 GB) is zoned to:
vio3 (hdisk59) - LUN is not assigned to any VTD device
vio4 (hdisk59), assigned to a NON-ACTIVE partition (in box GAIA) via vhost10 as lpar10_data01
WARNING - This LUN is not in use at the moment, however it is assigned for some -currently inactive- node(s) (Decommissioned server?)

600507920190817B8800000000000319 (16 GB) is zoned to:
vio5 (hdisk0) - LUN is not assigned to any VTD device
vio6 (hdisk77), assigned to HADES_lpar8 /Running/ (in box HADES) via vhost8 as lpar8_data01
WARNING - this LUN is not assigned to the HADES_lpar8 LPAR in a redundant way in the HADES box
WARNING - This LUN is not assigned properly, or the LUN is zoned for multiple VIO servers without purpose

600507920190817B8800000000000369 (16 GB) is zoned to:
vio5 (hdisk98), assigned to HADES_lpar10 /Running/ (in box HADES) via vhost10 as lpar10_data15
vio6 (hdisk97), assigned to HADES_lpar11 /Running/ (in box HADES) via vhost10 as lpar11_data15
WARNING - this LUN is assigned to multiple LPARs inside the HADES box. Is it on purpose (clustering)?

# Of course there would be no warning if there is nothing odd. However, if the LUN is not in use, then you will see something like that:

600507920190817B8800000000000230 (32 GB) is zoned to:
vio3 (hdisk53) - LUN is not assigned to any VTD device
vio4 (hdisk54) - LUN is not assigned to any VTD device
INFO - Spare LUN

.. and you can easily check the available spare LUNs (which are not assigned to any VTD device) via the -free command also :)

Disclaimer: Although the script only execute query commands (so it is unlikely that it could cause any harm) the script is not supported by IBM in any form, so use it at your own risk. In case you find a bug in the script please let me know.