Understanding Power System LPAR Profiles

LPAR profiles are a very important component to Power Systems because they control each LPAR’s resources. In this article, I’ll provide an overview of working with and using LPAR profiles. I’ll also discuss several common LPARprofile problems and their solutions.

LPAR Profile Overview

An LPAR profile describes what resources an LPAR will have available when it’s powered on, including items like CPU, virtual CPU, memory, physical I/O adapters, and virtual adapters. The LPAR profile also contains other settings for the LPAR, such the default boot mode for the LPAR and whether it should be automatically powered on when the managed system is powered on. LPAR profiles are managed from the Hardware Management Console (HMC).

For items such as CPU, virtual CPU, and memory, the profile specifies a minimum, desired, and maximum amount. It’s important to note that the minimum, desired, and maximum settings are only used to determine the amount of resources the LPAR has when it’s initially powered on and to set the boundaries for dynamic logical partitioning (DLPAR) operations. Figure 1 shows an example of the following settings:

• Minimum: Specifies the amount of resources required for the LPAR to power on. For example, if you specify a minimum of 2GB of memory and the system only has 1.8 GB of memory available, the LPAR won’t power on because the minimum wasn’t met. In addition, the minimum specifies the lower boundary for DLPAR operations. For example, if you set the CPU to a minimum of 2.0 processing units, you won’t be able to reduce the system to less than 2.0 processing units using DLPAR. Changing the minimum setting requires downtime on the LPAR.
• Desired: Specifies the amount of resources that the LPAR should have. When an LPAR is powered on, it will be assigned the specified amount of desired resources—unless the resources aren’t available. If the desired resources aren’t available, the LPAR will be assigned something in between the minimum amount and the desired amount (if the minimum amount isn’t available, the LPAR won’t activate.)
• Maximum: Specifies the upper boundary for DLPAR operations. For example, if you set the maximum memory to 16GB and have a requirement to go to 20GB, you won’t be able to use DLPAR because it would exceed the maximum setting. Changing the maximum setting requires downtime on the LPAR.

Figure 1: LPAR profile properties

DLPAR allows settings such as CPU, virtual CPU, and memory to be changed while an LPAR is running as long as the new settings are within the range between the minimum and maximum settings. DLPAR also allows physical I/O adapters and virtual I/O adapters to be added or removed while an LPAR is running.

Deciding what settings to choose for minimum, desired, and maximum can be difficult. Here are some suggestions and best practices:

• If available, look at performance monitoring tools such as NMON to understand what the requirements for the LPAR will be in order to come up with the “desired” setting for CPU and memory resources.
• Set the minimum setting fairly low; this will give you more flexibility in the future. For example, suppose you set an LPAR to have a minimum of 2 CPU resources, desired of 4, and maximum of 6, but it turns out that the LPAR is only using 0.5 of CPU at its peak. Since the minimum CPU setting is 2, you can’t DLPAR remove anything below 2 CPUs. Setting the minimum to a low amount expands the options for what you can do with DLPAR.
• Don't set the maximum too high—be realistic about the setting. The higher each LPAR's maximum setting is, the higher the overhead in the POWER Hypervisor. So if you have a system with 16 CPUs, don't set every LPAR to have a maximum of 16 CPUs. Instead, consider how much of the resources you think you might realistically need to DLPAR into the LPAR in the future.

It’s possible to have multiple LPAR profiles per LPAR. This can be useful if you need to boot up the same LPAR with different resources at different times. For example, at your disaster recovery site you might have an LPAR with a “DR profile” that has minimal CPU/memory resources and a “DR Failover Production” profile for the same LPAR that has much higher CPU/memory resources. Depending on your needs, you can choose which profile you want to activate.

It might also be helpful at times to boot up an LPAR without network access. This can be accomplished by creating a second profile and removing the physical or virtual network adapters from it. You can then activate this secondary profile and boot up the LPAR without network access. To do this, first select the LPAR in the HMC, then go to Configuration, Manage Profiles. Select the profile, then go to Actions, Copy, as Figure 2 shows.

Figure 2: Manage Profiles of a selected LPAR in the HMC

Name the new profile (perhaps with the server name, followed by “_no_net”), then edit this new profile and remove the physical or virtual network adapters. When you activate this profile, the server won’t have network access.

Running Configuration

It’s important to note that LPAR profiles are only used when an LPAR is powered on to determine its initial resource allocations. If you make changes to an LPAR profile, you must power off the LPAR and then activate it again for them to take effect.

Once the LPAR is powered on, it also has a “running configuration.” The running configuration is what the LPAR is currently configured to use. The LPAR profile and the running configuration might be different, which can cause issues because the running configuration is lost when the LPAR is powered off.

To view the running configuration of a system, click on the LPAR name link in the HMC, as shown in Figures 3 and 4.

Figure 3: View running configuration

Figure 4: Partition properties of "aix1"

There are two ways that the running configuration and LPAR profile can get out of sync: DLPAR and editing the profile of a running system. When resources are DLPARed into an LPAR, it only affects the running configuration. If you edit the profile of a running system, the changes won’t take effect until the LPAR is powered off and re-activated.

Here’s an example of how an LPAR profile and its running configuration can get out of sync:

1. An LPAR is created with minimum memory of 2GB, desired memory of 8GB, and maximum memory of 16GB.
2. The LPAR is powered on and has 8GB of memory, as specified in the desired setting.
3. Several months later, there are performance problems on the LPAR and the system administrator DLPARs in additional memory up to the LPAR's maximum of 16GB. DLPAR changes the running configuration, but not the LPAR profile. At this point, the profile and the running configuration are out of sync. The LPAR profile specifies 8GB of desired memory, but the LPAR's running configuration is 16GB of memory.
4. With the additional memory, the performance problem is resolved and everything is working great.
5. Several months later, all of the LPARs are shut down for a hardware replacement.
6. After the hardware replacement, the LPAR is powered back on and uses its profile to determine how much memory to assign the LPAR. The profile still shows 8GB of desired memory, so this is what the LPAR gets.
7. The LPAR performance problems are back, and the systems admin must now explain why the memory dropped back down to 8GB when everything was working great at 16GB.

In order to prevent problems like this, it’s generally recommended that you keep the running configuration and LPAR profile in sync. There are two different options available for doing so:

1. When you make DLPAR changes to an LPAR, update the profile by making the change there as well. For example, if you DLPAR change the memory to 16GB, edit the profile and change the desired memory to 16GB. However, don’t use this method for Virtual Fibre Channel Client adapters.
2. Use the Save Current Configuration option and overwrite the profile. This is only available in recent HMC versions and allows you to take everything in the running profile and overwrite the LPAR profile with these settings. For example, if you DLPAR change the amount of memory to 16GB and then use the Save Current Configuration option, the profile will be overwritten with the current running configuration, which includes the 16GB memory setting.

Comparing the LPAR Profile to the Running Configuration

We’ve covered the reasons why the LPAR profile and running configuration should be kept in sync. But how do you determine if they’re out of sync? Unfortunately, there isn't a built-in tool on the HMC to do this. To do it manually, you must compare each of the settings from the profile to the running configuration (which you access by clicking on the LPAR name link in the HMC). As you can see in Figure 5, manually comparing the LPAR profile to the running configuration can be very time consuming, because you need to compare CPU settings, memory settings, physical I/O adapters, virtual I/O adapters, etc.

Figure 5: Manually comparing LPAR profile to the running configuration

I’ve written a utility that automates the process of comparing LPAR profiles to their running configurations to make it very quick and easy to determine if they’re out of sync. The utility is named prdiff (Profile/Running Diff) and is available athttp://prdiff.sourceforge.net/. When you run the utility, it generates output similar to what’s shown in Figure 6, which highlights in red any differences between the LPAR profile and the running configuration.

Figure 6: prdiff utility output

Common LPAR Profile Issues and Solutions

There are a number of issues related to LPAR profiles. The following is a list of common problems and their solutions.

• Rebooting an LPAR to have profile change take effect. Some settings, such as the maximum amount of CPU or memory, aren’t changeable via DLPAR. To change one of these settings, you must edit the profile, then re-activate the LPAR. If you simply reboot the LPAR, the new profile won’t take effect: You must power off the LPAR, then power it on again.
• Setting the Maximum virtual adapters setting to low on VIO servers. The Maximum virtual adapters setting controls how many virtual adapters an LPAR can have. VIO servers quickly accumulate virtual adapters as the number of LPAR servers grow. This setting isn’t changeable via DLPAR and requires a shutdown/reactivation to change. Thus, on VIO servers, make sure to set this high enough to support the maximum number of LPARs you’ll have as VIO clients.
• Losing WWPNs on Virtual Fibre Channel client adapters. If you DLPAR in a new Virtual Fibre Channel client adapter to an LPAR, new WWPNs are created at the time the adapter is DLPARed in. If you then edit the profile and also add in the Virtual Fibre Channel client adapter to the profile, different WWPN's will be generated and stored in the profile. Consequently, the next time the LPAR is shut down and re-activated, it will have different WWPNs, which will likely cause serious issues for the LPAR. To prevent this, anytime you DLPAR add in Virtual Fibre Channel client adapters, use Save Current Configuration and overwrite the current profile. This will cause the same WWPNs from the running configuration to be saved into the LPAR's profile.
• Making a DLPAR change and not saving it to the profile. Anytime you make a DLPAR change, make sure the profile gets updated. Use the methods described in this article to keep your LPAR profiles and running configurations in sync. If not, the next time you shut down and re-activate your LPARs, they might not have the configuration they had before and, in some cases, they might not even boot!
• Not having a naming convention for LPAR profiles. If you have multiple profiles on an LPAR and no naming convention, it can be very confusing down the road. Make sure you have a consistent and documented naming convention for LPAR profiles. For example, the primary profiles for all the LPARs could be the server name followed by “_pri” or “_prod”. For temporary/testing profiles, you could name them the server name followed by “_temp”.

Conclusion

Properly managing and understanding LPAR profiles is critical to successfully administrating Power servers. After reading this article, I hope you understand the best practices for managing LPAR profiles and are able to avoid common issues related to them.


Courtesy POWER IT Pro.