AIX 6 Update

Another great Central Region Virtual users group meeting was held on Dec. 10. IBM's Jay Kruemcke covered what's new in AIX 6 since the release of TL4. If you missed the meeting, listen to the replay here and get the presentation materials here.

In response to a question about which features worked on which processors and versions of AIX, the organizers also posted this handy chart that details the requirements for enabling features like Live Partition Mobility, WPARs, virtual memory, etc.

Here are some other highlights:

* Workload Partition (WPAR) SAN support--According to Kruemcke, WPARs are able to own SAN devices, allowing WPAR administrators to directly manage their own storage, thus reducing administrative effort and increasing flexibility. So instead of running the lspv command inside of a WPAR and having nothing come back, you can map LUNs directly to your WPAR and use them as you would any other hdisk.

* N_Port ID Virtualization (NPIV) for Blade--The NPIV capabilities that have existed on our standalone servers are now available for our blade servers. I found this definition online: "NPIV enables a single HBA port to register several unique WWNs with the fabric, each of which can be assigned to an individual virtual machine." I tend to think of NPIV the same way I think of virtual Ethernet, where multiple logical devices use the same physical device.

* Fibre Channel over Ethernet Fibre Channel over Converged Ethernet (or commonly referred to as FC over Ethernet)--Jay says AIX will provide a native 10GB solution, and VIOS will facilitate sharing of this adapter.

* LPAR Mobility Phase 2--Says Jay: "VIOS will preserve slots and device names across Live Partition Mobility operation." Right now when you do a Live Partition Mobility operation, the virtual adapters get renumbered on the destination machine. If you move an LPAR back and forth a few times you can quickly end up needing to re-document which virtual devices are mapped to what.

* VIOS Usability Lightweight backup--This new VIOS option saves off just the customized data (such as device mappings and other pertinent ODM info) in a XML file. This allows backups to process much more quickly. Instead of saving the entire VIOS operating system, you're only saving what you need in order to rebuild your environment. The rest can be restored from install media.

Learn much more by listening to the presentation and the Q&A. Although keeping up with the changes in the operating system can be challenge, these free user group events are another relatively simple way to broaden your knowledge and invest in your career.

Migrations Made Simple with NIM

I had some VIO servers running 1.5.2.5-FP-11.1 SP-01 that I wanted to upgrade to 2.1.2.10-FP-22. The machines were in a remote location and consisted of both blade and "regular" servers. While I could have recruited someone to burn the migration .iso image and physically install the media into each DVD drive, I wanted to keep things simple. I decided to use NIM for the migration.

It helped that I could follow this great document that outlines the necessary steps for conducting an NIM migration.

I started by downloading the migration .iso image from here and the VIOS fixpack from here.

Then I loaded the migration .iso image into a virtual optical library (something I discuss here).

After making the DVD image available to a client LPAR using my virtual optical device, I mounted the DVD in the client LPAR. Then I used NFS to export the mounted DVD from my client LPAR over to my NIM server, which in this case happened to be a stand-alone server. Obviously, if my NIM server had been a client LPAR of my VIO server, I could have used the virtual optical directly to my NIM server, but I had to get a bit more creative here. Ultimately though, I accomplished my goal, which was to be able to mount the DVD image on my NIM server.

I made sure to bring my NIM server to the latest AIX level (6100-04-01-0944 as of this writing) and then followed the instructions in the aforementioned Migrate VIO document.

In my case, I first ran:

"gencopy -d /mnt -t /export/vios all"

After everything was copied from the optical media, I ran these commands:

"nim -o define -t lpp_source -a location=/export/vios -a server=master
vios_migration_lpp"

“nim -o define -t spot -a location=/export/spot -a server=master –a
source=vios_migration_lpp vios_migration_spot”

The first command defined my lpp source; the second defined my spot.

At this point I logged onto my NIM server so I could set up my NIM client to install using rte. (By the way, here's more info on NIM.)

I rebooted the VIO server and went into SMS mode. After verifying that the network installation settings were correct, I booted the VIO server from the NIM server. Then I selected the option to have it migrate my VIO server. Everything came up and ran as expected. After the reboot, it reported that it was at level 2.1.0.0.

Then I loaded the fixpack by NFS mounting my fix directory and running:

updateios -accept -install -dev /nfsmnt/fixes/vios.fixpack.22

At this point, my VIO server reported that it was at level 2.1.2.10-FP-22. That's where I wanted it.

Physical media is fine; use it all you want. But I'll take virtual optical and NIM every time.

The Case for Linux on Power

People occasionally ask me why they should run Linux on Power hardware. Their first inclination is typically to deploy Linux on some inexpensive commodity x86 hardware. They don't even think about the benefits of running Linux on Power. They believe they'll need to recompile their binaries to even get them to run. They assume the extra effort will outweigh the benefits.

As I've noted in "Lx86 Works as Advertised," you can run unmodified x86 binaries on top of Linux on Power by using Lx86. From IBM's PowerVM Lx86 for x86 Linux applications Web site:

"PowerVM Lx86 supports the installation and running of most 32-bit x86 Linux applications on any System p or BladeCenter model with POWER6, POWER5+ or POWER5 processors, or IBM Power Architecture technology-based IBM BladeCenter blade servers. It creates an x86 Linux application environment running on POWER processor-based systems by dynamically translating x86 instructions to Power Architecture instructions and caching them to enhance performance, as well as mapping x86 Linux system calls to Linux on POWER system calls. Best of all, no native porting or application upgrade is required for running most x86 Linux applications."

Recently I was at a session where Linux on Power was discussed. And a few benefits of running Linux on Power were raised that I think are worth noting.

1. IBM PowerVM virtualization technology provides the option of dynamically optimizing the mix of processor, memory, disk and network resources. This means that I can add just another LPAR to my frame to handle that Linux workload. Instead of going out and buying and managing another server, I just give it the necessary LUNs, shared Ethernet, memory and CPU allocation, and away I go.
2. Reliability matters. The IBM whitepaper "IBM Power Platform Reliability, Availability and Serviceability," is well worth reading. I'll highlight this point: "The base reliability of a computing system is, at its most fundamental level, dependent upon the intrinsic failure rates of the components that comprise it. Very simply, highly reliable servers are built with highly reliable components." Do you want your Linux machines running on commodity hardware, or do you want them running on reliable hardware?
3. Device drivers don't matter so much. Often you may find that there are no drivers for your hardware. However, this is less of an issue with Linux on Power, especially in a virtualized environment. Using a VIO server, how you get to the storage or the network isn't a concern; your VIO server handles that. You're just using a virtual adapter in your client LPAR. This allows you to use enterprise hardware without waiting for a device driver.
4. Power is less expensive overall. This is highlighted in an article on supercomputingonline.com titled, "IBM Power Systems Again Trump Latest Intel Offering, Highlights Total Systems Value." From the article: "According to an International Technology Group (ITG) report, three-year costs for use of Power servers ranged from 25-33 percent less than those built around commodity x86 servers in an SAP solution-based environment. Conversely, the three-year cost for the use of x86 servers was 48 percent higher than for Power servers in the retail industry, 49 percent higher in manufacturing, and 33 percent higher in energy. Costs outlined in the report include hardware acquisition and maintenance, systems software licenses and support, including operating systems and virtualization tools, personnel and facilities."

Obviously in some cases, running Linux natively on x86 hardware is the best choice. However, instead of dismissing the idea out of hand, take the time to research whether it might make sense to add a few LPARs to an existing enterprise frame.

On an unrelated note, check out this recent IBM statement of direction:

"IBM plans to provide an upgrade path from the current IBM Power 595 server with 12X I/O to IBM's next-generation POWER7 processor-based high-end server. The upgrade is planned as a simple replacement of the processor books and two system controllers with new POWER7 components, within the existing system frame. IBM also plans to provide an upgrade path from the current IBM Power 570 server with 12X I/O to IBM's next generation POWER7 processor-based modular enterprise server."

This is good news if you've been debating whether to order a POWER6 server now or wait until POWER7 comes out. Now you can have the best of both--POWER6 performance now, and POWER7 when it ships.

IBM Hardware Fits in the Big Picture

I've worked for numerous companies that were IBM customers. For several years I worked for IBM in Boulder, Colo. I currently work for an IBM business partner. Through all this time, I've been happily using IBM racks with IBM servers. Sure, there were other servers running other operating systems that used different racks in the various computer rooms, but the IBM servers all lived in IBM racks.

I was recently on a raised floor at a server co-location company and watched IBM customer engineers move a POWER5 Model 570 from an IBM rack to a non-IBM rack. To install the server, they had to carefully measure its required depth. To make the flex cable on the front of the machine fit into the rack, they had to modify the side of the rack due to some protruding metal on the side doors that was interfering with the flex cable. Obviously, the whole operation took longer than a regular rack install into a standard IBM rack would have taken.

While they got the server to work in the non-IBM rack, it wasn't an ideal situation. The power distribution units in the back of the rack were rotated compared to the IBM rack, and the plugs were oriented so that when the servers were plugged in, power supplies and PCI cards couldn't be swapped without removing the entire PDU first.

So why go to this trouble? These non-IBM racks are taller and have a smaller footprint than the previously used IBM racks. When you're paying by the square foot, you want to squeeze in as much equipment as you can. By using extra space at the top of the rack, the co-locator could fit more equipment into its floor space. I can certainly understand that with several taller, narrower racks, you can wedge more racks into a row of hardware, and that can translate into more revenue for the operators of the shared environment. (This might not matter so much in a customer-owned data center, but in this shared environment, it's critical.)

One of the facility managers said that IBM just doesn't get co-location. He argues that every other vendor can make its equipment fit into these racks, why can't IBM?

My take is that IBM engineering designs IBM racks with IBM hardware in mind. They're rugged. They're built to fit without modification, and they're built so that parts can be easily hot-swapped in and out of the machines. If IBM racks don't fit nicely into your cookie cutter server room that was designed with non-IBM servers and racks in mind, if they're wider than other enclosures, then maybe it's time to rethink the design of the room. The problem as I see it is that many customers think that everything is the size of an x86 machine. However, they should plan for equipment of other sizes. It's not necessary to redesign the computer room--but maybe designating an aisle for nonstardard-sized racks would give them some flexibility.

The thing is, the greater serviceability of IBM solutions is well worth the sacrifice of some floor space. IBM engineering designed and built its racks with IBM servers in mind. Using PowerVM and IBM Power Systems servers, you can consolidate multiple large workloads onto a much smaller footprint. And isn't creating the smallest footprint the goal here? Yes, IBM racks might take up an extra square foot or two compared to non-IBM racks, but this should be easily offset by an overall reduction in server hardware.

I believe IBM keenly understands co-location. They've given me hardware that I can easily carve into
multiple LPARs per physical frame, which allows me to consolidate workloads. The technology is very forgiving and flexible--as workloads grow and change, it's very easy to use a dynamic LPAR operation and make the adjustment.

Ultimately of course, the customer is always right. So if you need to make your server fit into a smaller footprint on your raised floor, you can and should do so. But first, reconsider what you're giving up by making this change. Saving physical space doesn't always equate to saving money.

Another Case for Using the Command Line

Live partition mobility is a topic I've covered previously in an AIXchange blog post titled, " Getting Hands-On with Live Partition Mobility." More recently, Chris Gibson wrote a great Web exclusive article for IBM Systems Magazine titled, "Using the Command-Line Interface for LPM," that talks about performing live partition mobility migrations from the command line.

To make sense of articles like Chris', I like to take them to the lab. Basically I run through many of the same commands that he lists in his article. So if you read both his article and this post, you'll have two different perspectives of doing migrations from the command line on two different sets of blades.

I ran the commands that he provided and in my environment, I used two blades. (In the output below, my command line entries start with #. The output is on the next line.)

Blade 1:
#lssyscfg -r sys -F name
Server-7998-61X-SN100BB8

Blade 2:
#lssyscfg -r sys -F name
Server-7998-61X-SN1004DAA

I have many partitions running on each blade, so I'll list only the VIOS partition on each blade (10-0BB8A and vios_server, respectively) and the partition (aix6san1) that I migrated:

Blade 1:
#lssyscfg -r lpar -F name,state
10-0BB8A,Running
aix6san1,Running

Blade 2:
#lssyscfg -r lpar -F name,state
vios_server,Running

Blade 1:
#lslparmigr -r lpar
name=10-0BB8A,lpar_id=1,migration_state=Not Migrating
name=aix6san1,lpar_id=6,migration_state=Not Migrating

Blade 2:
#lslparmigr -r lpar
name=vios_server,lpar_id=1,migration_state=Not Migrating

Chris explains that by using the LSLPARMIGR command with the proper parameters, we can learn some virtual adapter mappings that can be used during the migration. My source system (Server-7998-61X-SN100BB8) needs to know the server that's being migrated to (Server-7998-61X-SN1004DA) as well as its IP or hostname (blade12), the LPAR name that's migrating (aix6san1) and the appropriate attributes (suggested_virtual_scsi_mappings in this case).

#lslparmigr -r virtualio -t Server-7998-61X-SN1004DA --ip blade12
--filter lp ar_names=aix6san1 -F suggested_virtual_scsi_ mappings

2/vios_server/1

Again, using commands Chris provided, I ran the command to verify that the migration would run, (-o v means to validate only; -t is the name of the destination managed system, --ip is the IP address or hostname of the HMC or IVM managing the destination system and --id is the ID of the partition on which to perform the operation). The command ran for a bit, and then returned no output. Using the echo $? command, we can see the return code, which confirms that the command successfully executed.

#migrlpar -o v -t Server-7998-61X-SN1004DAA --ip blade12 --id 6
#echo $?
0

By running the same command from before and changing the option –o v to –o m, I started the migration. And, using the techniques listed in Chris’ article, I could verify the successful migration of my LPAR.

# migrlpar -o m -t Server-7998-61X-SN1004DAA --ip blade12 --id 6

In one instance I migrated from one blade to the other, but didn't receive verification that it was ready to migrate back. I ran the command from the second blade, and the migration process hung. By using the –o r (recover) option, it was able to clear out the operation. (In one instance, I also had to use the --force parameter.)

As Chris states, whether you want to automate live partition mobility from the command line or manually perform a migration from the VIOS command line instead of using the GUI, scripts are a great option for AIX admins. Creating a script would allow you to use cron if, for instance, you want to move a partition at a particular time of day. This provides you with a predefined action that's ready to go; all you have to do is run the script and the partition will move. This can be much simpler than logging in and pointing and clicking on different GUI screens.

We are not Windows administrators. For the most part we do our work from command lines. While point-and-click can seem easier at times, it's still important to remember that most of the things you can do in GUI can also be done from the command line. There will be situations where running partition migrations directly from the command line makes the most sense.

Console Counseling

Having a Hardware Management Console (HMC) in your environment has its benefits. You can remotely power a machine on and off. You can remotely get to a console from the HMC. You can use the HMC to create logical partitions. And, should problems arise with the actual POWER server or the HMC, IBM can help you. If you're using another vendor's solution for your remote console and remote "power off and on" solutions, who knows what kind of support you might get from them if things are not working properly.

After running your machine in stand-alone mode with an async terminal for a console, you may have an issue defining your console after you attach it to the HMC. Sometimes when logging into the HMC and trying to bring up a console window, I've seen strange characters on the screen, or no characters at all. I call this gobbledygook, though I'm not sure that phrase translates well for our international readers.

In one scenario, IBM Support had me remove devices from the ODM and then reboot, so that it would give me the opportunity to select the console. On another occasion, the machine was still in manufacturing default configuration (MDC) and IBM had a document that advised us to take it out of MDC. In each case, the console worked fine once I followed IBM's suggestions.

I thought I'd pass on these items should you ever find yourself with a non-working console from your HMC. If you click on the links below, you can find information on the problems and the solutions.

• "Problem: Terminal window to the default partition is unusable on new managed systems due to system being in MDC. Symptom: Users receive garbage characters on terminal window to newly added p5 or p6 managed systems or do not get a login prompt once default partition is activated."
• "Problem: System p is newly attached to an HMC and the server property for MDC is false. The vterm console works in hardware mode (i.e., SMS and for displaying hardware parameters when LPAR is activating). However, the vterm does not display login prompt after AIX has been booted. Cause: AIX was installed on system p server when it was attached to an async console prior to attaching system to HMC."

Read both of these links and add them to your toolkit. As always, if you get stuck, call IBM Support. They will know how to help you.

IBM Installation Toolkit for Linux Does More Than Just Install Linux

Don't be taken in by the title--the IBM Installation Toolkit for Linux isn't just for installing Linux. From IBM: "The IBM Installation Toolkit for Linux provides a set of tools that simplifies the installation of Linux on IBM Power Systems. The toolkit also provides IBM value-added software that you can install, so that you can take advantage of Power Systems capabilities, such as Dynamic Logical Partitioning (DLPAR). The toolkit also supports Web-based updates, providing immediate access to the latest offerings.

"The Toolkit can also be used as a rescue bootable DVD to run diagnostic tools and repair previously installed operating systems. It also provides a wealth of IBM documentation for configuring and managing Power systems.

"The Toolkit is available as a single ISO image that that you can download from this website. This image can be used to create a bootable DVD or to create a network installation server, which makes multiple and parallel Linux installations over the network possible."

While I plan on using it to install Linux, I first wanted to check out the Toolkit's other features. First, I downloaded the .iso image. As always, I prefer virtual optical instead of physical media. So I went to my virtual I/O (VIO) server and ran:

mkrep -sp datavg -size 16G

Then I ran:

oem_setup_env
cd /var/vio/VMLibrary/
scp source_machine:/path/to/iso.image ./

This copied the .iso image to my VIO server so that I could assign it as a virtual optical device.

I did a DLPAR operation on my HMC to add a virtual SCSI adapter to my VIO server. Then I ran cfgdev on my VIO server so that I could see the adapter.

And then I ran:

mkvdev -fbo -vadapter vhost3
loadopt -vtd vtopt0 -disk IBM_Installation_Toolkit.iso

lsmap showed me:

vhost3

VTD                   vtopt0
Status                Available
LUN                   0x8100000000000000
Backing device        /var/vio/VMLibrary/IBM_Installation_Toolkit.iso
Physloc

After assigning the virtual SCSI adapter to my client LPAR, I was then able to boot from this CD image.

Once I booted the machine, I got a root prompt. Then I entered:

WelcomeCenter

After accepting the license, I was presented with these options:

Install Linux
Utilities
Help

I went into the Utilities and saw:

Configure network
Eject Media
Reboot System
System Diagnostics
Firmware Update

The System Diagnostics has:

System Properties
System Inventory
Error Log
Service Configuration
Boot Configuration

These look like useful tools, and if I boot from this CD image I don't need to have an OS installed to run the utilities. Once I've had more time to explore them, I'll report back with more findings.

More from IBM:

"The server consolidation tool provided by the Toolkit tackles the most time-consuming and error-prone aspect of server consolidation: the migration of OS stack and user and application data. With the Toolkit, the administrator can quickly put a new server into production. The tool targets the migration and customization of LAMP stack (Linux - Apache - mySQL - Perl, Python, and PHP) and data from
X86 servers running RHEL 4, RHEL5, SLES9 and SLES10 to Power Systems.

"The administrator has complete control over the installation and migration process. He chooses the level of the OS and whether additional RPMs should be installed as well as whether to migrate user accounts and data. So whether you intend to migrate one or more servers, the new server consolidation tool is sure to save you a lot of time.

"The IBM Installation Toolkit is intended for customers who want to:

• Install and configure Linux on a non-virtualized Power System.
• Install and configure Linux on machines with previously configured Logical Partitions (virtualized machines).
• Install IBM RAS Tools along with Linux or on a previously installed system.
• Upgrade firmware level on Power Systems.
• Perform diagnostics or maintenance operations on previously installed systems.
• Improve application performance using the latest Power Systems optimizations available in the Advance Toolchain.
• Migrate LAMP stack from X86 RHEL and SLES servers to Power Systems.
• Browse and search Linux documentation included on the Toolkit ISO. "

Can You Restore? Now's the Time to Find Out

A buddy recently told me about a situation he encountered where a non-disruptive disk update on a storage area network proved extremely disruptive. The client lost its LUNs, which impacted all of the LPARs that were booting from SAN, along with many machines that had datavg stored out in the SAN.  Rootvg on these partitions was gone.

Still, the client figured it could restore its environment from their most recent backups. However, this was a test environment. There were no backups. The machines were built and used, with no thought ever given to recovering them. Since this wasn't production, it wasn't important enough to add jobs to the backup server to accommodate these machines, right?

This was another painful lesson learned. The machines had to be rebuilt. The scripts, users, tools and code that was being developed were lost.

I, for one, have covered this topic repeatedly, because it's important. Yet some continue to ignore the message. I still find environments that don't have consistent, recent backups. Yes, IBM hardware is robust, and it's known for reliability and availability. But even the best hardware is still man-made, and machines break. And even the most experienced administrators logon and make mistakes. Stuff happens.

To this, some respond: "I have nothing to worry about in my environment. I take my weekly mksysb. I send the tapes offsite. I take my nightly backup. It goes over the network to my backup server, which we then offload to tape, which we then take offsite."

But do you test those backups? Are you sure the tapes can be read? I'm not even talking about a true disaster-recovery scenario, where your building burned down and you're trying to rebuild. I'm talking about simply trying to restore data to machines in your current environment.

When you really need to restore isn't the time to find out that you can't restore. It's critical that you take the time to confirm this now, when things are still running smoothly.

Ask yourself what will be lost if you must go back to your last backup. Did you take that backup last night? If your outage happened right before closing time, is your business prepared to rollback to last night's backup and redo the work that was done during the day?

More and more the answer is no: Outages any kind and any length cannot be tolerated.

Constantly look at your environments. If you add file systems to machines, are the new file systems being backed up? Is the frequency of the backups acceptable to the business? Does management agree with your conclusion?

The objective of a backup is to be able to restore. Be sure that you can.

Making the Case for AIX and Power Systems

I recently received an e-mail from a mailing list that linked these documents from The Sageza Group and Forrester Research. Both reports offer information that may help non-technical personnel understand the value proposition of AIX and Power Systems.

In "The Value of PowerVM Workload Partitions New Virtualization Options in IBM AIX v6.1," Sageza focuses on on workload partitions (WPARs). I've previously covered WPARs here, here and here.

While the Sageza report is apparently accessible online, Forrester's report, "Virtualization Trends On IBM's System p: Unraveling The Benefits In IBM's PowerVM," seems to be available only through registration and subscription. From Forrester:

"IBM's PowerVM (formerly Advanced POWER Virtualization) technology has catalyzed the consolidation of server systems resources and a variety of applications workload types--both AIX- and Linux-led--as virtualized on more powerful multi-core System p servers. Evolution of IBM's virtualization stack has improved dramatically--from its early 2001 introduction of logical partitions on the first multicore POWER4-based systems--to its current PowerVM virtualization stack. In 2007, IBM's refresh to POWER6 came fast and furious: debuted with high-end System p 570 (in May), followed by the P6-based JS22 blade (November), and sweeping through the System p 520 (entry) model and System p 550 (midrange) server (January 2008). Traction for PowerVM virtualization now accounts for 70 percent of its IT customer base -- showing to what extent IBM's virtualization stack has become a shortlist contender as a systems consolidation enabler. The November 2007 release of AIX 6 added two breakthrough features--Live Partition Mobility and Live Application Mobility--further cementing IBM's advanced virtualization advantages against its Unix competitors.

"1. What's the history behind the IBM virtualization stack?
2. What is the overall business value of the System p virtualization stack?
3. What role does the POWER Hypervisor play in the PowerVM?
4. How does the POWER Hypervisor integrate with PowerVM technologies?
5. What are the benefits of micro-partitioning and the shared-processor pool?
6. What are workload partition (WPAR) and Live Application Mobility?
7. What business problems are solved with PowerVM's new Live Partition
Mobility?"

And, from Sageza:

"Many organizations have embraced virtualization to improve IT utilization and reduce the expenses associated with equipment acquisition, installation and operation. While traditional virtualization or partitioning schemes have improved IT resource utilization, reducing the number of physical servers has not reduced the number of server operating system (OS) images requiring administration and maintenance. If anything, virtualization has encouraged growth in the number of servers that support the application workloads in organizations. There is an opportunity for IT to reduce this administrative overhead to become more streamlined and cost-efficient while continuing to provide the levels of service on which organizations have become dependent.

"IBM AIX 6.1, through its support for Workload Partitions, enables organizations to rethink the way they deploy multiple workloads on a single server. While traditional approaches such as virtualization using logical partitioning provide OS isolation and independence, for many workloads, this degree of isolation exceeds the user's need and results in unnecessary administrative and operational overhead.

"WPARs offer IT managers a more cost-effective yet secured approach that meets the needs of many organizations. WPARs differ from other partitioning or virtualization schemes in that they partition server resources by the workload and share access to a single OS image. This is in contrast with the more common approach of creating a discrete operating system image to support each virtual server. By reducing the number of OS images required, the level of server software maintenance and other related IT administrative and management activity can be decreased while maintaining streamlined operational management and reduced need for physical resources.

"WPARs increase resource utilization from the typical 5-20 percent average, reduce partition creation and teardown times, and reduce the number of OS instances and associated system management workload. WPARs provide standard application environments, support mobility and templates as well as cloning, and have automated policy-based resource and workload management through the WPAR manager. Consolidating with WPARs saves floor space and reduces the power consumption and expense associated with servers and air conditioning in the data center while maintaining the one-app/one-server deployment paradigm.

"In this paper, we examine the flexibility that WPARs offer IT professionals in their virtualized UNIX server environments. In particular, we review how WPARs are different from other partitioning technologies and how WPARs complement existing environments. We discuss the capabilities and practical uses of WPARs in sample scenarios and articulate the ways in which WPARs provide an alternative to other partitioning schemes. Through AIX 6.1 and its support for WPARs and PowerVM Live Application Mobility, IT managers have greater flexibility in server configuration and can select the best approach to meet the user organization's needs while also simplifying the operational and cost efficiency of the IT environment."

Script Changes

I received an interesting e-mail from a mailing list. Included was this information submitted by Dean Rowswell:

1. Turn on PuTTY logging
2. Copy and paste these 6 commands first:

lshmc -v
lshmc -V
lshmc -r
lshmc -n
lshmc -b
lssysconn -r all
lssyscfg -r sys
lssyscfg -r frame
lshmc -n -F clients
cat /opt/hsc/data/.hmc/.removed
lspartition -dlpar
lspartition -sfp

3. Copy and paste these commands last:

for MANAGEDSYS in `lssyscfg -r sys -F type_model*serial_num`
do
echo "============MANAGED SYSTEM --> ${MANAGEDSYS}"
echo " ============MANAGED SYSTEM --> LIC level"
lslic -m ${MANAGEDSYS} -t sys
echo " ============MANAGED SYSTEM --> processor config"
lshwres -m ${MANAGEDSYS} -r proc --level sys
echo " ============MANAGED SYSTEM --> lpar processor usage"
lshwres -m ${MANAGEDSYS} -r proc --level lpar -F
lpar_name:curr_proc_mode:curr_sharing_mode:run_proc_units:run_procs
echo " ============MANAGED SYSTEM --> memory config"
lshwres -m ${MANAGEDSYS} -r mem --level sys
echo " ============MANAGED SYSTEM --> lpar memory usage"
lshwres -m ${MANAGEDSYS} -r mem --level lpar -F lpar_name:run_mem
echo " ============MANAGED SYSTEM --> lpar status"
lssyscfg -m ${MANAGEDSYS} -r lpar -F name:state
echo " ============MANAGED SYSTEM --> cuod processor config"
lscod -m ${MANAGEDSYS} -t cap -r proc -c cuod
echo " ============MANAGED SYSTEM --> cuod memory config"
lscod -m ${MANAGEDSYS} -t cap -r mem -c cuod
echo " ============MANAGED SYSTEM --> drawer config"
lshwres -m ${MANAGEDSYS} -r io --rsubtype unit
echo " ============MANAGED SYSTEM --> bus config"
lshwres -m ${MANAGEDSYS} -r io --rsubtype bus
echo " ============MANAGED SYSTEM --> slot config"
lshwres -m ${MANAGEDSYS} -r io --rsubtype slot
echo " ============MANAGED SYSTEM --> slot config summary"
lshwres -m ${MANAGEDSYS} -r io --rsubtype slot -F
drc_name:description:lpar_name:lpar_id
echo " ============MANAGED SYSTEM --> virtual ethernet"
lshwres -m ${MANAGEDSYS} -r virtualio --rsubtype eth --level sys
echo " ============MANAGED SYSTEM --> virtual ethernet all lpar"
lshwres -m ${MANAGEDSYS} -r virtualio --rsubtype eth --level lpar
echo " ============MANAGED SYSTEM --> virtual scsi all lpar"
lshwres -m ${MANAGEDSYS} -r virtualio --rsubtype scsi --level lpar
for LPAR in `lssyscfg -r lpar -m ${MANAGEDSYS} -F name`
do
echo " ============LPAR --> ${LPAR} --> CPU resources"
lshwres -r proc -m ${MANAGEDSYS} --level lpar --filter lpar_names=${LPAR}
echo " ============LPAR --> ${LPAR} --> Memory resources"
lshwres -r mem -m ${MANAGEDSYS} --level lpar --filter lpar_names=${LPAR}
echo " ============LPAR --> ${LPAR} --> Physical adapters"
lshwres -r io --rsubtype slot -m ${MANAGEDSYS} --filter lpar_names=${LPAR}
echo " ============LPAR --> ${LPAR} --> Virtual Ethernet config"
lshwres -r virtualio --rsubtype eth --level lpar -m ${MANAGEDSYS}
--filter lpar_names=${LPAR}
echo " ============LPAR --> ${LPAR} --> Virtual SCSI config"
lshwres -r virtualio --rsubtype scsi --level lpar -m ${MANAGEDSYS}
--filter lpar_names=${LPAR}
echo " ============LPAR --> ${LPAR} --> LPAR config"
lssyscfg -r lpar -m ${MANAGEDSYS} --filter lpar_names=${LPAR}
echo " ============LPAR --> ${LPAR} --> LPAR profiles"
lssyscfg -r prof -m ${MANAGEDSYS} --filter lpar_names=${LPAR}
done
done

4. Copy and paste these lines to add the information to my LPAR resource allocation spreadsheet
NOTE: when I do a paste into Excel click on the paste options and select "Text import wizard"

for MANAGEDSYS in `lssyscfg -r sys -F type_model*serial_num`
do
echo "============MANAGED SYSTEM --> ${MANAGEDSYS}"
lshwres -m ${MANAGEDSYS} -r io --rsubtype slot -F
unit_phys_loc:bus_id:phys_loc:description
done

For System p machines that already have the physical resources assigned:

for MANAGEDSYS in `lssyscfg -r sys -F type_model*serial_num`
do
echo "============MANAGED SYSTEM --> ${MANAGEDSYS}"
lshwres -m ${MANAGEDSYS} -r io --rsubtype slot -F
unit_phys_loc:bus_id:phys_loc:description:lpar_id:lpar_name
done

5. To capture any errors and events

lssvcevents -t hardware
lssvcevents -t console

After messing around with the script, I wanted to get it working from cron. I'm unable to run scripts on my HMC, but after looking here, I set up my ssh keys so I could auto login from my AIX machine to my HMC.

Then I modified the above script so I could run it from my AIX machine and have it connect to my HMC using ssh. Now I can run the job out of cron on my AIX machine instead of messing with putty.

#!/usr/bin/ksh
#
# scriptname -m hmchostname -l hmcuser
#
#
hmc=hmc.ip.address

user=hscroot

while getopts m:l: option
do
case $option in
m) hmc="$OPTARG";;
l) user="$OPTARG";;
esac
done

echo "HMC Information:"
echo ""
ssh $hmc -l $user 'date'
ssh $hmc -l $user 'lshmc -v'
ssh $hmc -l $user 'lshmc -V'
ssh $hmc -l $user 'lshmc -r'
ssh $hmc -l $user 'lshmc -n'
ssh $hmc -l $user 'lshmc -b'
ssh $hmc -l $user 'lssysconn -r all'
ssh $hmc -l $user 'lssyscfg -r sys'
ssh $hmc -l $user 'lssyscfg -r frame'
ssh $hmc -l $user 'lshmc -n -F clients'
ssh $hmc -l $user 'cat /opt/hsc/data/.hmc/.removed'
ssh $hmc -l $user 'lspartition -dlpar'
ssh $hmc -l $user 'lspartition -sfp'

for MANAGEDSYS in `ssh $hmc -l $user "lssyscfg -r sys -F type_model*serial_num"`
do
echo "============MANAGED SYSTEM --> ${MANAGEDSYS}"

echo " ============MANAGED SYSTEM --> LIC level"
ssh $hmc -l $user "lslic -m ${MANAGEDSYS} -t sys"
echo " ============MANAGED SYSTEM --> processor config"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r proc --level sys"
echo " ============MANAGED SYSTEM --> lpar processor usage"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r proc --level lpar -F
lpar_name:curr_proc_mode:curr_sharing_mode:run_proc_units:run_procs"
echo " ============MANAGED SYSTEM --> memory config"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r mem --level sys"
echo " ============MANAGED SYSTEM --> lpar memory usage"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r mem --level lpar -F
lpar_name:run_mem"
echo " ============MANAGED SYSTEM --> lpar status"
ssh $hmc -l $user "lssyscfg -m ${MANAGEDSYS} -r lpar -F name:state"
echo " ============MANAGED SYSTEM --> cuod processor config"
ssh $hmc -l $user "lscod -m ${MANAGEDSYS} -t cap -r proc -c cuod"
echo " ============MANAGED SYSTEM --> cuod memory config"
ssh $hmc -l $user "lscod -m ${MANAGEDSYS} -t cap -r mem -c cuod"
echo " ============MANAGED SYSTEM --> drawer config"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r io --rsubtype unit"
echo " ============MANAGED SYSTEM --> bus config"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r io --rsubtype bus"
echo " ============MANAGED SYSTEM --> slot config"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r io --rsubtype slot"
echo " ============MANAGED SYSTEM --> slot config summary"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r io --rsubtype slot -F
drc_name:description:lpar_name:lpar_id"
echo " ============MANAGED SYSTEM --> virtual ethernet"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r virtualio --rsubtype
eth --level sys"
echo " ============MANAGED SYSTEM --> virtual ethernet all lpar"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r virtualio --rsubtype
eth --level lpar"
echo " ============MANAGED SYSTEM --> virtual scsi all lpar"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r virtualio --rsubtype
scsi --level lpar"

for LPAR in `ssh $hmc -l $user "lssyscfg -r lpar -m ${MANAGEDSYS} -F name"`
do
echo " ============LPAR --> ${LPAR} --> CPU resources"
ssh $hmc -l $user "lshwres -r proc -m ${MANAGEDSYS} --level lpar
--filter lpar_names=${LPAR}"
echo " ============LPAR --> ${LPAR} --> Memory resources"
ssh $hmc -l $user "lshwres -r mem -m ${MANAGEDSYS} --level lpar
--filter lpar_names=${LPAR}"
echo " ============LPAR --> ${LPAR} --> Physical adapters"
ssh $hmc -l $user "lshwres -r io --rsubtype slot -m ${MANAGEDSYS}
--filter lpar_names=${LPAR}"

echo " ============LPAR --> ${LPAR} --> Virtual Ethernet config"
ssh $hmc -l $user "lshwres -r virtualio --rsubtype eth --level lpar -m
${MANAGEDSYS} --filter lpar_names=${LPAR}"
echo " ============LPAR --> ${LPAR} --> Virtual SCSI config"
ssh $hmc -l $user "lshwres -r virtualio --rsubtype scsi --level lpar
-m ${MANAGEDSYS} --filter lpar_names=${LPAR}"
echo " ============LPAR --> ${LPAR} --> LPAR config"
ssh $hmc -l $user "lssyscfg -r lpar -m ${MANAGEDSYS} --filter
lpar_names=${LPAR}"
echo " ============LPAR --> ${LPAR} --> LPAR profiles"
ssh $hmc -l $user "lssyscfg -r prof -m ${MANAGEDSYS} --filter
lpar_names=${LPAR}"
done
done

for MANAGEDSYS in `ssh $hmc -l $user "lssyscfg -r sys -F type_model*serial_num"`
do
echo "============MANAGED SYSTEM --> ${MANAGEDSYS}"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r io --rsubtype slot -F
unit_phys_loc:bus_id:phys_loc:description"
done

for MANAGEDSYS in `ssh $hmc -l $user "lssyscfg -r sys -F type_model*serial_num"`
do
echo "============MANAGED SYSTEM --> ${MANAGEDSYS}"
ssh $hmc -l $user "lshwres -m ${MANAGEDSYS} -r io --rsubtype slot -F
unit_phys_loc:bus_id:phys_loc:description:lpar_id:lpar_name"
done

ssh $hmc -l $user 'lssvcevents -t hardware'
ssh $hmc -l $user 'lssvcevents -t console'

Feel free to improve upon what Dean and I have done so far. I'll add your contribution to a future posting.