Update :
I juste realized I never did the same quick one-liner for the NPIV case, which is indeed what my servers are built on , I’m fixing it right now !
VSCSI
When working with VSCSI mode, I always find the lsmap -all output to be a real pain in the *ss, because of all the formatting, and the scrolling you have to do to find your lpar when you don’t know which vadapter is related to the lpar you’re looking for :
# lsmap -all SVSA Physloc Client Partition ID --------------- -------------------------------------------- ------------------ vhost4 U9117.MMB.999BCP-V2-C8 0x00000008 VTD d7f1_lpar1 Status Available LUN 0x8100000000000000 Backing device hdisk25 Physloc U78C0.001.DBJ1531-P2-C5-T1-W50060F80164D0B26-L17000000000000 VTD d7f1n1_lpar1 Status Available LUN 0x8200000000000000 Backing device hdisk26 Physloc U78C0.001.DBJ1531-P2-C5-T1-W50060F80164D0B26-L18000000000000 VTD r7f1_lpar1 Status Available LUN 0x8300000000000000 Backing device hdisk24 Physloc U78C0.001.DBJ1531-P2-C5-T1-W50060E80164DFB26-L16000000000000 [...] # lsmap -all |wc -l 170
…170 lines … Jeez…
To fix this, I found this nice combination of options with lsmap command :
# lsmap -all -field vtd svsa -fmt : vhost0:d7f1_lpar2:d7f1n1_lpar2:d7f1n2_lpar2:r7f1_lpar2:t7f1_lpar2 vhost1:d7f1_lpar3:d7f1n1_lpar3:d7f1n2_lpar3:d7f1n3_lpar3:d7f1n4_lpar3 vhost2:d7f1_lpar4:d7f1n1_lpar4:r7f1_lpar4:t7f1_lpar4 vhost3:d7f1_lpar5:d7f1n1_lpar5:d7f1n2_lpar5:r7f1_lpar5:t7f1_lpar5 vhost4:d7f1_lpar1:d7f1n1_lpar1:r7f1_lpar1
No need to run wc -l here, you’ll have only the same number of lines as the number of vadapters (5 lines here) .
What about NPIV ?
The problem doesn’t lie within the VTDs, but here we need sometimes to get to the point quickly: is my Virtual server correctly mapped to the VIO’s physical FC adapter? What’s the distribution between all my VIO’s adapters ? How many hosts are connected ?
Basic line to display every VFC adapter and the attached hosts
# lsmap -all -npiv -field "FC name" Status Name ClntName -fmt : vfchost0:lpar1:fcs0:LOGGED_IN vfchost1:lpar2:fcs0:LOGGED_IN vfchost2:lpar3:fcs0:LOGGED_IN vfchost3:lpar4:fcs0:LOGGED_IN vfchost4:lpar5:fcs0:LOGGED_IN vfchost5::fcs1:NOT_LOGGED_IN
See ? 5 lpars actually talking through the VIO’s physical adapter fcs0, and one mapped to fcs1, but not active at this moment.
Which lpars are not mapped to a physical adapter
# lsmap -all -npiv -field "FC name" Status Name ClntName -fmt : |grep -v fcs vfchost23: : :NOT_LOGGED_IN
Here we only have one and we don’t know its name, because it isn’t mapped at all, maybe we’ll need the ClntID field to determine which lpar we’re talking about.
Which lpar are not connected (maybe shut down)
lsmap -all -npiv -field "FC name" Status Name ClntName -fmt : |grep NOT|grep fcs vfchost20: :fcs0:NOT_LOGGED_IN
Here the mapping has been made (because we can see that fcs0 is configured on this vfchost) but the lpar is not active.
What is the FCS distribution on your VIO Server ?
# /usr/ios/cli/ioscli lsmap -all -npiv -field "FC name" -fmt : | sort -n | uniq -c 1 22 fcs0 6 fcs1 9 fcs4 5 fcs5
As you can see, the distribution is far from perfect … we have 22 hosts mapped to fcs0, although only half a dozen hosts are mapped on each other adapter …
Then fcs0 is having much much more activity than the other FC adapters! It is bad, knowing that we have 4 FC adapters with 8GB/s bandwitdth available… and we’re really actually using only one…
Note that there is also one port not logged_in (first blank line on the previous output).
About that …
There is a recent improvement with the latest HMC microcode and VIO release 2.2.2.1, which enables you to choose the destination FC adapter when you achieve live partition migration (before that update, no matter what you do, if you migrate a lpar, you will always be mapped to fcs0, even if you have 8 ou 16 FC adapters. It is really a huge improvement for us, and I guess for you too
)
My friend at chmod666.org just wrote a nice post about that, please pay him a visit, he’s worth the trip : http://chmod666.org/index.php/improved-control-for-live-partition-mobility-choose-your-destination-fibre-channel-port/
Bonus
Hint : you can also check that easily by issuing the lsnports command, just look at the « aports » number (43 aports with 64 tports means that there are 64-43=21+1 mapped but not logged in = 22 hosts on fcs0)
# lsnports name physloc fabric tports aports swwpns awwpns fcs0 U5803.001.9SS99BC-P2-C6-T1 1 64 43 2048 1967 fcs1 U5803.001.9SS99BC-P2-C6-T2 1 64 58 2048 2030 fcs4 U5803.001.9SS99BC-P2-C8-T1 1 64 55 2048 2017 fcs5 U5803.001.9SS99BC-P2-C8-T2 1 64 59 2048 2033
Hope it helps !



Hi, inspired by your discovery I beged a friend to help me with the formating of the data and changed a thing or two and out came this script (hopefully the formating of the code survives in this message box)
Code:
#!/usr/bin/perl @output = `/usr/ios/cli/ioscli lsmap -all -field clientid svsa physloc vtd lun backing bdphysloc status -fmt ,`; foreach $line (@output){ my ($svsa, $physloc, $vtd, $lun, $backing, $bdphysloc, $status); while ( $line =~ /(\S+),(vhost\d+),([^,]*)/gc ) { $lparid = hex($1); $svsa = $2; $physloc = $3; print "########## $svsa ##########\n"; printf "%-20s %-15s\n", LPAR_ID, $lparid; while ($line =~ /,(.+?),0x(.+?),(.+?),(.+?),([^,]*)/gc){ $vtd = $1; $lun = $2; $backing = $3; $bdphysloc = $4; $status = $5; printf "%-20s %-15s %-10s\n", $vtd, $backing, $status; } print "\n"; } }Hope you find it as helpful as I do!
Regards Sebastian
oh crap each double quote got changed to double redirection… keep that in mind when you copy the code.
Hi sebastian, and thanks for the perl script, it gives a nice output!
For other readers the output looks like this :
For the double quotes, I took care of that, as you can see