- 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)
# zoning_info.shUsage:zoning_info.sh -make : Gather all the necessary details from the HMC(s) managed VIO Server(s)zoning_info.sh -all : Check all LUNszoning_info.sh -free : List the spare LUNszoning_info.sh LUN1,LUN2 : Check the specific LUN_ID(s) (separated by ',' )
600507920190817B8800000000000178 (32 GB) is zoned to:vio1 (hdisk26), assigned to a NON-ACTIVE partition (in box ZEUS) via vhost3 as lpar3_data01vio2 (hdisk26), assigned to a NON-ACTIVE partition (in box ZEUS) via vhost3 as lpar3_data01vio3 (hdisk48), assigned to GAIA_lpar6 /Running/ (in box GAIA) via vhost6 as lpar6_data03vio4 (hdisk48), assigned to GAIA_lpar6 /Running/ (in box GAIA) via vhost6 as lpar6_data03WARNING - 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 devicevio4 (hdisk59), assigned to a NON-ACTIVE partition (in box GAIA) via vhost10 as lpar10_data01WARNING - 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 devicevio6 (hdisk77), assigned to HADES_lpar8 /Running/ (in box HADES) via vhost8 as lpar8_data01WARNING - this LUN is not assigned to the HADES_lpar8 LPAR in a redundant way in the HADES boxWARNING - This LUN is not assigned properly, or the LUN is zoned for multiple VIO servers without purpose600507920190817B8800000000000369 (16 GB) is zoned to:vio5 (hdisk98), assigned to HADES_lpar10 /Running/ (in box HADES) via vhost10 as lpar10_data15vio6 (hdisk97), assigned to HADES_lpar11 /Running/ (in box HADES) via vhost10 as lpar11_data15WARNING - this LUN is assigned to multiple LPARs inside the HADES box. Is it on purpose (clustering)?
600507920190817B8800000000000230 (32 GB) is zoned to:vio3 (hdisk53) - LUN is not assigned to any VTD devicevio4 (hdisk54) - LUN is not assigned to any VTD deviceINFO - Spare LUN
UPDATE (2017.06.30) - Uploaded the latest release of the script. CHANGELOG:
# 0.4.4.0 (2016-01-29) - Updated the script as IBM did patch the oem_setup_env\ncommand bug
# 0.4.4.1 (2016-01-29) - Fixed a bug, where the underscore character in frame names could cause unexpected behaviors
# As that was used as a separator character previously. Now the separator is set to '*#*'
# 0.4.4.2 (2016-01-30) - Fixed a bug that did not report the LUN associated LPAR when the LPAR got deleted
# 0.4.4.3 (2016-01-30) - Fixed a bug that occurred when the detected LUNs were labeled as "Other FC SCSI Disk Drive"
# 0.4.4.4 (2016-02-06) - Fixed a bug that affects some EMC (and possibly other) LUNs that have strange Serial numbers with special characters in them
# Added a few additional checks (like size check)
# 0.4.4.5 (2016-03-29) - Fixed a compatibility issue with VIOS 2.2.4.x (ODM structure has changed compared to 2.2.3.x)
# 0.4.4.6 (2016-12-01) - Fixed a bug related to the -free function (LUNs have been queried multiple times)
# 0.4.4.7 (2017-05-10) - ODM query modified a little bit - lsvg is not verified in ioscli before passing the arguments to it since VIOS 2.2.5.x