VIOS disk mapping in a nutshell

When patterns are not followed and names do not mean anything

Have you found yourself doing some kind of troubleshooting on servers which you have never touched before? Nowadays, working in huge companies or even as a consultant, you might not be able to avoid such situations. To avoid mistakes in VIOS and LPAR environments, this article will simply show you how to map disk devices within VIOS server without caring about name patterns. In the end, you will see how name patterns are important and how to bypass them if required.

Leandro Ferreira da Silva (ldfsilva@gmail.com), Integration engineer, Hewlett-Packard

Leandro Ferreira da SilvaLeandro Silva got started with UNIX® systems by working with FreeBSD servers; afterwards, he got an opportunity at IBM where he worked as an UNIX system administrator dealing with critical and complex AIX and Solaris environments. Currently, he works as an integration engineer at Hewlett-Packard. You can reach him at ldfsilva@gmail.com.



24 January 2012

Also available in Chinese Russian

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.


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.


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#

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$

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.

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=788672
ArticleTitle=VIOS disk mapping in a nutshell
publish-date=01242012