VIOS disk mapping in a nutshell

Introduction

This article shows you in a simple way about how to identify existent customer disk configuration within VIOS servers.

Most of the time, UNIX® administrators get confused in environments set with PowerVM due to unknowns. Typically, system administrators, who support critical customer applications, did not have a chance to set the environment from the beginning. For this reason, they were not able to implement their own name pattern, rules, and so on.

Here you will see how to get started in reverse mapping environments which do not have a name pattern for disk mapping.

Forget names

We'll start with forgetting the names. For this we need the number of the LPAR to identify VIOS disks mapping.

Since you are connected in the LPAR, you can issue the uname -L command to get its number; the number we want is the first sequence of characters followed by the LPAR name.

Listing 1. Getting LPAR number

root@a25acdldm001g::/> uname -L 69 h3j5lp69 root@a25acdldm001g::/>

In our example above, the LPAR number of the a25acdldm001g server is 69 and its LPAR name is h3j5lp69. Now that we have the LPAR number, we can continue with our disk mapping. For now, the only thing missing is the disk itself; so let's check rootvg volume group and see what we find.

Issuing the lsvg -p rootvg command, we can see which disks are part of the rootvg volume group.

Listing 2. Getting VG disks listed

root@a25acdldm001g::/> lsvg -p rootvg rootvg: PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION hdisk0 active 639 12 00..00..00..00..12 root@a25acdldm001g::/>

The result is just one disk in the rootvg, hdisk0.

Back to top

Gathering initial information

So, where does hdisk0 come from?

That is a difficult question to answer. However, when working with PowerVM, you need to know how to dig into this question.

The lspath command can give us the initial hint.

Listing 3. Getting disk details

root@a25acdldm001g::/> lspath -l hdisk0 Enabled hdisk0 vscsi0 Enabled hdisk0 vscsi1 root@a25acdldm001g::/>

Based on the output above, we can see that hdisk0 comes from vscsi0 and vscsi1, respectively. The problem is that either vscsi0 or vscsi1 is a virtual device which came from the VIOS server.

We don't have our answer yet, so further investigation still needs to be done.

For those who are not familiar with PowerVM technology, one of its benefits is to offer disk mapping through VIOS servers. Taking advantage of it can save you HBAs usage, increase availability, gain flexibility in LPARs, reduce costs, and so on. That's why this kind of configuration is highly used.

The next important point we need to be aware of is the slot number of the virtual scsi devices.

We can get that by issuing the lscfg -l vscsiX command, where X is the number we have previously (i.e., 0 and 1).

Listing 4. Getting vscsi slot number

root@a25acdldm001g::/> lscfg -l vscsi0 vscsi0 U9117.MMA.10F2F1A-V69-C10-T1 Virtual SCSI Client Adapter root@a25acdldm001g::/> root@a25acdldm001g::/> lscfg -l vscsi1 vscsi1 U9117.MMA.10F2F1A-V69-C11-T1 Virtual SCSI Client Adapter root@a25acdldm001g::/>

We are almost there! We have almost everything needed to map our disk.

LPAR number (69), vscsi slot numbers (C10 and C11), by now it is missing just the HMC which the frame is connected to.

Do not worry if you do not have this information written somewhere, you can get it by running the lsrsrc command as follows:

Listing 5. Getting HMC Details

root@a25acdldm001g::/> lsrsrc IBM.ManagementServer Resource Persistent Attributes for IBM.ManagementServer resource 1: Name = "10.1.120.24" Hostname = "10.1.120.24" ManagerType = "HMC" LocalHostname = "10.1.82.69" ClusterTM = "9078-160" ClusterSNum = "" ActivePeerDomain = "" NodeNameList = {"a25acdldm001g"} root@a25acdldm001g::/>

Now we have everything needed to complete our mapping. It is as simple as that.

Back to top

Where does hdisk0 come from?

Open up a new session to the HMC and let's identify from which VIOS server hdisk mapping is being done.

Being connected as hscroot user, you can issue the lshwres command to get such information.

Listing 6. VIOS and slot number

hscroot@h3j5hmc1:~> lshwres -m h3j5 -r virtualio --rsubtype scsi --level lpar --filter \ "lpar_ids=69" -F slot_num,remote_lpar_id,remote_slot_num 10,3,69 11,4,69 hscroot@h3j5hmc1:~>

You should ask yourself what those numbers in bold mean.

• 10,3,69 (10 is the vscsi slot number on the LPAR numbered 69; 3 is the remote ID (VIOS number); 69 is the slot number on the VIOS numbered 3)
• 11,4,69 (11 is the vscsi slot number on the LPAR numbered 69; 4 is the remote ID (VIOS number); 69 is the slot number on the VIOS numbered 4)

Note: In case your HMC manages more than one frame, and you are unsure about which one your LPAR is running on, you can issue the following commands to get its frame name. In my case, I know the frame name is h3j5.

Being logged on your LPAR you can get its frame serial number by issuing the lsattr command as follows:

lsattr -El sys0 -a systemid

After you get the serial number of the frame, you can go back into the HMC and search for its name as follows:

lssyscfg -r sys -F name,serial_num|sed '/your serial number goes in here/!d'

Now we just need to access the respective remote_lpar_ids mentioned above (i.e.: VIOS servers) to check which vhost is assigned to that specific slot and then map its disks.

As we already have the remote LPAR ID number (i.e.: VIOS server), we do not even need to care about its name. For example:

Listing 7. Getting into VIOS server

hscroot@h3j5hmc1:~> mkvterm -m h3j5 --id 3 Open in progress Open Completed. IBM Virtual I/O Server login: padmin padmin's Password: 1 unsuccessful login attempt since last login. Last unsuccessful login: Thu May 20 19:43:36 EDT 2010 on /dev/vty0 Last login: Thu May 20 11:41:58 EDT 2010 on /dev/vty0 h3j5vioss1$

Since you log on the VIOS server, you need to go to VIOS server mode by issuing the oem_setup_env command (i.e., this command is used to switch from VIOS to AIX mode).

h3j5vioss1$ oem_setup_env h3j5vioss1#

Listing 8. Discovering what the vhost is for the slot number 69.

h3j5vioss1# lsslot -c slot|grep "C69 " U9117.MMA.10F2F1A-V3-C69 Virtual I/O Slot vhost69 h3j5vioss1# ^d ( going back to VIO mode )

If you are lucky, either the slot or vhost has the same number; however, they could be completely different.

Since we've identified the vhost assigned to slot 69, we have all we need to check what is being mapped to our LPAR numbered 69.

h3j5vioss1$ lsmap -vadapter vhost69 SVSA Physloc Client Partition ID --------------- -------------------------------------------- ------------------ vhost69 U9117.MMA.10F2F1A-V3-C69 0x00000045 VTD 69_368 Status Available LUN 0x8100000000000000 Backing device hdisk121 Physloc U789D.001.DQD79BX-P1-C1-T1-W5005076801300F0A-L76000000000000 VTD 69_369 Status Available LUN 0x8200000000000000 Backing device hdisk122 Physloc U789D.001.DQD79BX-P1-C1-T1-W5005076801300F0A-L77000000000000 h3j5vioss1$ oem_setup_env ( going back to AIX mode )

As shown above, both hdisk121 and hdisk122 are being mapped to our LPAR from VIOS server 3.

Now let's take a look at what their redundancy looks like in multi-path.

Listing 9. Checking disks redundancy

h3j5vioss1# lspath -l hdisk121 Enabled hdisk121 fscsi0 Enabled hdisk121 fscsi0 Enabled hdisk121 fscsi1 Enabled hdisk121 fscsi1 Enabled hdisk121 fscsi2 Enabled hdisk121 fscsi2 Enabled hdisk121 fscsi3 Enabled hdisk121 fscsi3 h3j5vioss1# lspath -l hdisk122 Enabled hdisk122 fscsi0 Enabled hdisk122 fscsi0 Enabled hdisk122 fscsi1 Enabled hdisk122 fscsi1 Enabled hdisk122 fscsi2 Enabled hdisk122 fscsi2 Enabled hdisk122 fscsi3 Enabled hdisk122 fscsi3 h3j5vioss1#

In the information above, we can assume that SAN folks have mapped both LUNs for all of the four HBAs in the VIOS server 3 (i.e., from fcs0 through fcs3 ).

One of the quickest ways to get their respective WWPNs for an eventual disk allocation would be:

h3j5vioss1# for i in 0 1 2 3;do echo "fcs${i} -> $(lscfg -vl fcs${i}|sed '/Network/!d')" \ ;done fcs0 -> Network Address.............10000000C9881EA8 fcs1 -> Network Address.............10000000C9881EA9 fcs2 -> Network Address.............10000000C9881EB4 fcs3 -> Network Address.............10000000C9881EB5 h3j5vioss1#

Back to top

Final notes

All steps performed in VIOS server 3 should be performed in VIOS server 4 as well. We need to discover which vhost in VIOS server 4 is mapping disks to the LPAR 69 and then check its respective redundancy.

Better than simply getting disk details in Listing 3, we could specify other options in the lspath command to get a little bit more useful information that can help us identify the real name of the disks in the VIOS server mapped through the vhost to the LPAR.

So, how do we know for sure that the hdisk0 in the LPAR 69 is the hdisk121 in the VIOS server 3?

Here's how you do it:

root@a25acdldm001g::/> lspath -l hdisk0 -F name,parent,connection,status hdisk0,vscsi0,810000000000,Enabled hdisk0,vscsi1,810000000000,Enabled root@a25acdldm001g::/>

By simply checking the connection value in the lspath command output, we can see that it exactly matches with the value shown in the lsmap command. For example:

h3j5vioss1$ lsmap -vadapter vhost69 SVSA Physloc Client Partition ID --------------- -------------------------------------------- ------------------ vhost69 U9117.MMA.10F2F1A-V3-C69 0x00000045 VTD 69_368 Status Available LUN 0x8100000000000000 Backing device hdisk121 Physloc U789D.001.DQD79BX-P1-C1-T1-W5005076801300F0A-L76000000000000 VTD 69_369 Status Available LUN 0x8200000000000000 Backing device hdisk122 Physloc U789D.001.DQD79BX-P1-C1-T1-W5005076801300F0A-L77000000000000 h3j5vioss1$

Back to top

Conclusion

Finally, we are able to understand this environment. The LPAR numbered 69 has one disk on its rootvg which is being delivered through two VSCSIs. From the HMC we discovered that each VSCSI comes from a different VIOS server (i.e., VIOS number 3 and VIOS number 4).

In addition, we discovered that hdisk0 on LPAR numbered 69 is hdisk121 on the VIOS servers number 3, and we also saw that they are mapped to all of the four HBAs (fcs[0-3]) on the VIOS server.

If you didn't understand all that was covered in this article, read it once more and focus on the bold words and also on the numbers. It can help you to fix this mapping concept.

Here's a recap of what was covered:

• LPAR
  • Get the LPAR number.
  • Get the disk name.
  • Get the slot number based on the vscsi device.
• HMC
  • Get VIOS slot number.
  • Get VIOS number.
• VIOS
  • Use VIOS slot number to get the vhost.
  • Show disks which are being mapped to the vhost which you discovered.
  • Make sure which one is the correct disk based on the connection number.
  • Check disk paths.