This post is a list of the steps taken to map virtual SCSI disks back to the VIO servers on an AIX system. I had to carry out this process recently and decided to write up the steps for future reference. Hopefully this can be of some help.
All scripts are run from NIM server and with keys exchanged between lpars, VIO servers and HMCs. SAN disks are allocated to VIO servers and are mapped to LPARs from VIOS.
I recently had to document the mappings for a number of LPARs, documenting which disks led to which SAN LUNs on the respective VIO servers and found there was still no easy way to do this from the LPAR itself, so had to come up with a process to do so.
Step 1 – gather information from LPAR
First step is to gather info from AIX server which we would like to map back to the VIO. this can be done in a number of ways, but we will use lsdev -Cc disk to check for Virtual SCSI disks, then the lspath command to trace slot numbers back to the VIO. Once we determine that hdisk0 is served by our vio server, we could just use lscfg -l hdisk0 to find the local slot number, however this is a dual vio environment and it is necessary to check that the slot numbers are the same on each vio server. Hence we will use lspath -F “name,status,parent,connection” -l hdisk0 to give full mapping info to both VIO servers.
# lspath -F "name,status,parent,connection" -l hdisk0
From this output, we can see that there are two paths to this disk, through vscsi0 and vscsi1. Each vscsi device maps to a vhost device on a VIO server. As this is a dual VIO server configuration, we can assume that each path is a vhost device on a separate VIO server. Also, each path has the same LUN number of “810000000000″, suggesting that both VIO server are in sync and have the same vhost mapping. As each vhost / vscsi device can map multiple LUNs, each client LUN has an id beginning at “810000000000″, then “820000000000″, 83xxx and so on.
So, now we need the client slot number for each device. Again there are multiple ways of doing this, including lscfg -l vscsix, however it’s neater to use lsslot -c slot to find everything we need:
# lsslot -c slot
# Slot Description Device(s)
U8205.E6C.0123ABC-V12-C4 Virtual I/O Slot vscsi0
U8205.E6C.0123ABC-V12-C5 Virtual I/O Slot vscsi1
From here, we can see that the LPAR ID is represented by V12 and the client slots are C4 and C5 repectively. Cool, now we need the info from the HMC to get the server slots. Unfortunately, this is a bit of a faff and we need to log into the HMC to trace this back. I will provide a script to automate this process, however it’s important that we understand the steps involved before we can do so.
This can be done from the GUI, but for speed, we will go to the command line. So, from the HMC command line you need to type the following:
-> lssyscfg -r sys -F "name" | grep 0123ABC
U8205-E6C-0123ABC-> lshwres -r virtualio --rsubtype scsi -m U8205-E6C-0123ABC --filter lpar_ids=12 -F "slot_num,remote_slot_num,remote_lpar_name"
See here for more on command line basics.
However, this is easier done from the NIM server if you have your ssh keys set up. See here, for more info on setting or resetting your ssh keys on NIM.
nim01 # ssh -q hscroot@hmc1 lssyscfg -r sys -F "name" | grep 0123ABC
nim01 # ssh -q hscroot@hmc1 lshwres -r virtualio --rsubtype scsi -m U8205-E6C-0123ABC --filter lpar_ids=12 -F "slot_num,remote_slot_num,remote_lpar_name"
Obviously replace hscroot@hmc1 with your username@hmcname and -m <systemname> with your system name.
Now to gather the info from the VIO server. You can do this by logging into the VIOS as padmin and typing lsmap -all |more and search through till you find your slot number from before (24 in our case).
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost14 U8205.E6C.0123ABC-V1-C24 0x0000000c
Backing device hdiskpower01
Backing device hdiskpower02
From here we can see that the vhost device at slot 24 (vhost14) is holding a number of disks. We can identify the disk we looked up from earlier by refering to the LUN ID of 810000000000. We know this is hdisk0 from the LPAR information.
Now see that the backing device for this is hdiskpower01. This is because I’m using EMCPower software for my MPIO. This value may read hdiskX in your case. If so, you won’t need to follow the steps required for mapping the EMCPower disks.
So, from this information, we can run an lspv on the VIO server to find the physical disk
vio33a # lspv | grep hdiskpower1
hdiskpower1 00f7e02exxxx1111 rootvg active
Of course if the pvid was set up correctly (by installing with: chdev -l hdiskpower01 -a pvid=yes), then we could possibly just take the pvid of each disk from the LPAR and grep for that same pvid on the VIO server.
lpar1 # lspv | grep hdisk0
hdisk0 00f7e02exxxx1111 rootvg active
padmin@vio33a $ lspv |grep 00f7e02exxxx1111
hdiskpower1 00f7e02exxxx1111 None
However, this is not always reliable if these steps were not followed correctly during setup, so we will continue with this, more robust method.
So now we have the hdiskpower device on the VIO server. If we want to find the actual SAN LUNs which were mapped via EMCPower Path, we need to execute the following command:
root@vio33a # powermt display dev=all |grep -p hdiskpower1$
Logical device ID=1ABC
state=alive; policy=SymmOpt; priority=0; queued-IOs=0;
--------------- Host --------------- - Stor - -- I/O Path -- -- Stats ---
### HW Path I/O Paths Interf. Mode State Q-IOs Errors
0 fscsi0 hdisk3 FB 8fA active alive 0 0
1 fscsi1 hdisk7 FB 9fB active alive 0 0
So now we finsally have a mapping of the LUN ID, 1ABC and the low level disks used on the VIO server from the SAN software. Now we need to do that for the second VIO server and alll the other disks, while we’re at it!
Pain the neck?
Indeed, so we need a way of automating this process. I’ve adapted a small perl script to suite my needs. As previously stated, all command are run from my NIM server, which has passwordless ssh access to all lpars and the HMCs. From here, we can gather all the information we want and blat it out to a file.