April 15, 2014

Device Mapping on IBM i

More and more IBM i administrators who once relied exclusively on internal disks are now getting their disks from VIOS using vSCSI or NPIV. These administrators need a handy way to determine which SAN LUNs correspond to which individual virtual disks in IBM i. If your SAN administrator wants to know which LUN is DD001 on the IBM i client, how do you respond?

In disparate computing environments, it's a question that's bound to come up. Maybe the SAN admin is making some changes and wants to take back a LUN, and the IBM i admin needs to be able to determine which LUN is allocated to which virtual disk in the IBM i environment. Maybe the administrator temporarily used an internal hdisk and is now migrating to a SAN LUN. Whatever the reason, there are certainly times when you want to know which backing device is being used in an IBM i environment.

Luckily, this document is available to help with the cross-referencing.

Problem (Abstract)

This document describes how to cross-reference (device mapping) IBM i disk units with VIOS disk units.

Resolving the problem

At some point, you may need to know the physical location of the virtual disk units. This information might be needed for performance measurements or service, or you might need to be able to translate to and from IBM i to VIOS to the physical devices (including an external disk, if relevant). This document describes how to map the i drives to the VIOS drives and then to the physical disks.

These scenarios are presented in this document:

1) Check device mapping from the HMC -- With HMC version 7.3.4 SP2 or later you can see the device mapping from the HMC if the server is HMC Managed.

2) Find the device mapping in a single adapter client partition -- Another way to do this mapping is by calculating the LUN from the Controller number. Back on the Display Disk Unit Details screen, we know that DD001 is on Controller 3. You should convert the controller number from decimal to hex and then add 0x80. In this case, Decimal 3 = 0x03 + 0x80 = 0x83. Looking at the lsmap, we can see the LUN 0x083 is hdisk9.

Mapping the i drive to the correct hdisk becomes important if you ever want to remove disk units from the partition. After you have removed the disk unit from the ASP, you must be able to determine which hdisk to remove from the partition profile.

3) Multiple adapter client partition -- If you need to identify disks, you will need to know which virtual adapter (vhost) has the correct mapping. In this case, we need to look at the SYS Card identifier. This number identifies the client adapter ID in the partition you are working with. In a multiple adapter environment, the controller number is not unique. Therefore, you also need to determine which adapter you are looking at. To do this, you need to use the Sys Card Number from the Display Disk Unit details above. You may use either HMC or IVM to view the partition properties. Partition ID 4 has two client adapters. They connect to server adapters 401 and 403, respectively. View the server partition properties/virtual adapters tab to see the information.

4) vios command line interface on VIOS 2.1.2.X and IBM I R6.1.1 or later -- If this is an IVM environment with multiple SCSI adapters you can use the following command to map the disks.

Use this command to get the system name:
lssyscfg -r sys -F name

Use the system name as input into the following command:
lshwres -m <system name> -r virtualio --rsubtype scsi --level lpar -F topology

5) The system card number explained -- Above in the multiple adapter example disk unit's details showed that the Sys Card field was 145 for 16 of the drives, and 147 for the remaining 15. Why is the sys card field a different number than the HMC or IVM adapter ID? The Sys Card field wraps at 256. So if you add 145 and 256, you get 401. Likewise, if you add 147 and 256, you get 403. We also need to keep in mind that it is possible to have more than one Sys Card of the same number because customers can configure the adapter ID. For example, looking at an IBM i partition disk unit details there are 62 disk units in various ASPs. There are two Sys Card 33s listed in the details.

Looking at the partition properties, you see the following:




Adapter ID

Connecting Partition

Connecting Adapter

Server SCSI




Server SCSI




U9117.MMA.1007E34-V1-C801 = vhost1
U9117.MMA.1007E34-V1-C33 = vhost2

256 + 256 + 256 + 33 = 801
33 = 33


Have you had to map LUNs back to IBM i disks? What methods did you use?

April 08, 2014

Good Things to Bookmark

If you've never heard of the POWER Systems Reference, you're in for a treat. This site catalogs a host of basic informational and support resources.

For instance, the Quick Ref tab provides (among other things):

Default FSP Addresses











 Phone Numbers

888-426-4357  IBM HELP

800-426-2255  IBM Direct

800-426-4968  IBM 4 YOU

800-225-5249  CALL AIX

800-300-8751  Rochester Quality Hot Line

800-426-5463  Poughkeepsie Quality Hot Line


877-603-2145  Mechanicsburg Parts

800-678-4727 Opt. 1 Parts Administration

888-426-4357 Opt. 4,1,2 RETAIN

Public Links

Assist On Site - AOS

CoD Activation Codes

Code - IBM Support Portal

Code Compatibility Matrix



Info Center

Sales Manual

The HMC Menu tab features sample HMC menus for either systems or frames, along with examples of scenarios covering HMC connections. There's also an ASMI menu table, which, as you can imagine, displays ASMI menus (that can vary based on your firmware level).

The POWER tabs (POWER8, POWER7, POWER6, POWER5, POWER4) cover the different models of hardware including links to adapter placement, sales manuals and IBM Redbooks.

The information here is so valuable, I can't help but wonder why I never thought of doing something similar myself. I guess I should just be grateful that I don't have to.

While I'm at it, the QuickSheets and QuickStart guides are also worth bookmarking.

Feel free to cite your favorite online resources in comments.

April 01, 2014

A tmux Primer

I wrote this piece about screen and vnc for IBM Systems Magazine 10 years ago, and I still refer to it, because I still use screen and vnc. However, I must admit that tmux is giving screen a run for its money these days.

A ton of good tmux tutorials are available, but I'll start with this one:

"tmux is useful to people in different ways. To me, it's most useful as a way to maintain persistent working states on remote servers—allowing you to detach and re-attach at will… you can use tmux to have multiple panes within multiple windows within multiple tabs within multiple sessions."

Indeed, tmux does provide another way to look at detachable sessions. But why should a loyal screen user (like me) go learn something new?

"tmux is a lot like screen, only better. The short answer for how it's better is that tmux is better designed to perform the same functions. Screen gets you there (kind of) but does so precariously.

"Here are a few of the key advantages of tmux over screen:

l    Screen is a largely dead project, and its code has significant issues

l    Tmux is an active project with an active codebase

l    Tmux is built to be truly client/server; screen emulates this behavior

l    Tmux supports both emacs and vim shortcuts

l    Tmux supports auto-renaming windows

l    Tmux is highly scriptable

l    Window splitting is more advanced in tmux

Enough about that. Use tmux."

As I said, there are several other good tutorials on tmux. I also recommend this two-parter (here and here). is the place to get tmux for AIX. Or start here if you're unsure of how to get all the dependencies from

Once you master tmux, you won't look back -- and again, this is coming from a long-time screen user. Lately I've even been thinking that it would be nice if we could use tmux to reconnect to persistent sessions on the HMC.

Are you already using tmux? How about other persistent tools? I'm always looking for new things. Are there tools you'd recommend to me?

March 25, 2014

Resolving an Issue with Dual HMCs

Recently, a customer was unable to run a DLPAR command against some of the LPARs on their frame. That in itself isn't unusual. Generally in these situations the network isn't communicating between the HMC and the LPAR, or perhaps RMC daemons need to be restarted somewhere.

This environment had dual HMCs connected to the managed system. HMC1 controlled some of the LPARs and HMC2 controlled others, but not by design. Although there was no rhyme or reason to it, for simplification let's say that HMC1 was controlling LPAR1 and LPAR3 and HMC2 was controlling LPAR2 and LPAR4. The correct setup would have been HMC1 and HMC2 controlling LPAR1, LPAR2, LPAR3 and LPAR4. In reality approximately 40 LPARs were on the frame, with each HMC controlling approximately half of the LPARs.

If you were on HMC1, you could DLPAR LPAR1 and LPAR3 with no issues. If you were on HMC2, you could DLPAR LPAR2 and LPAR4 with no issues. The problem was that the only way to know which HMC was controlling which LPAR was to either login to the HMC command line and run lspartition –dlpar, or use the HMC GUI and select HMC Management > View Network Topology. There was no way to know which HMC you needed to login to to manage which LPAR. This headache needed to be resolved.

Initially we did some troubleshooting with IBM Support. That resulted in us running things like:

            /usr/sbin/rsct/bin/rmcctrl –p


We tried getting root access via pedbg. We also tried collecting a snap:




Eventually, once we escalated high enough up the support food chain, someone noticed a very basic HMC setup problem:


            The LPAR IBM.MgmtDomainRM default file shows this msg where it's attempting to create a    IBM.MCP entry for hmc1. It fails with Error number 14, duplicate key for localhost.

            2610-652 The specified time limit has been exceeded.
            Mon Feb 17 13:04:32 CST 2014(439849)      ../../../../../src/rsct/rm/MgmtDomainRM/MCP_cfg.c/01438/1.22  2613-034 Error number 14 was          returned when attempting to define an IBM.MCP resource.
            2610-014 The key token localhost is a duplicate.

During the initial build of the HMCs, they had been given their unique hostname and IP address, but somehow someone made a change that resulted in both hostnames being reset to localhost. Since these HMCs had the same hostname and ran on the same network, only one of the two was capable of managing LPARs at any given time. The other one would always fail.

Needless to say, if you run multiple HMCs, make sure they have unique hostnames. And in any environment, it's essential to establish good change control so people aren't making changes to systems without proper approvals and documentation.

March 18, 2014

Installing Language Filesets

If you've ever installed locale files on your AIX server, you might appreciate my recent predicament. A customer's application team recently asked me to install bos.loc.utf.EN_US as part of their overall installation. The file exists on the installation media, but not in .bff format. So how do you install it?

Web searching was of little help (perhaps I didn't enter the most accurate search terms). In any event, my searches turned up links like this, this and this, none of which were what I was really looking for. I just wanted to learn how to install the filesets.

Through blind luck and poking around, ultimately I went into smitty > system environments > manage language environment > add additional language environments.

For both the cultural convention to install and the language translation to install I selected:

            UTF-8    English (United States) [EN-US]


I told it where to find the files, and it worked.

I cut and pasted my smitty screen below. Hopefully this will help you visualize what I'm talking about:


                        Add Additional Language Environments


            Type or select values in entry fields.

            Press Enter AFTER making all desired changes.


                                                                          [Entry Fields]

            CULTURAL convention to install                 UTF-8             English (U> +

            LANGUAGE translation to install                 UTF-8             English (U> +

            * INPUT device/directory for software         [/dev/cd0]                   +

            EXTEND file systems if space needed?        yes                               +


            WPAR Management

              Perform Operation in Global Environment     yes                             +

              Perform Operation on Detached WPARs       no                              +

                Detached WPAR Names                            [_all_wpars]                +

              Remount Installation Device in WPARs      yes                               +

              Alternate WPAR Installation Device            []


The process to install this fileset was easier than I'd expected (as using smitty usually is), though less intuitive than I'd hoped (you have to know to go into the language environments in the first place).

Incidentally, one reason I'm writing about this this experience is simply to have it documented somewhere. I actually will do web searches when I'm working on an issue, and find the answer in a link to something I'd written years earlier. In fact it happens fairly often. So as much as I enjoy sharing with readers, I admit I have another, slightly selfish motivation for writing these posts. Sometimes they help Future Me solve problems. Hopefully Future Me will appreciate the time I took to write about this particular issue.