Manage LPAR startup order and validate resource allocation with system profiles

Make your LPARs work as a team


Why use system profiles?

With hardware and power redundancy, you might think that planning for a system outage is redundant. After all, IBM Power Systems are made to be resilient. Even so, there are still reasons why a server can go down. Ideally, that will only happen with a planned outage, such as when you have to do a disruptive firmware upgrade. But whether the outage is planned or completely unexpected, when your server does get powered down and needs to be powered on again, it's better to be ready for it. You need to know how to power off and, more importantly, power on a managed system (see Related topics). It's important to be aware of the shutdown and startup procedures, particularly the startup order of your LPARs.

The virtualization capabilities of IBM Power Systems allow you to divide the resources of one physical server into many LPARs. In the (thankfully rare) event of an outage on a Power System, all the LPARs that belong to it are affected. When you power on again using the HMC (see Related topics), problems with LPAR activation can become apparent.

For example, the same resource may have been flagged as required for two LPARs when their partition profiles were configured via the HMC (see Related topics). If that happens, then if the first LPAR is activated, the second LPAR's activation will fail because it is missing a required resource. Another potential show stopper occurs when there is not enough memory or processing capacity to go around. Some LPARs are activated and get their desired allocation. Then other LPARs can't be activated because they don't even get their minimum memory or processor requirements.

A common issue that you may not discover until it's time to restart the managed system is that some LPARs need to start before other LPARs that depend on them. For instance, if you use Virtual I/O Servers (VIOS) to share physical I/O resources, then you need to start the VIOS before the LPARs that depend on them for disk space or network connectivity. Similarly, a database LPAR needs to be up before an application server LPAR that connects to that database.

You can address these issues ahead of time—rather than during a system outage—by using system profiles.

What is a system profile?

A system profile is an ordered list of logical partition profiles. System profiles are a way of grouping partition profiles together.

Strictly speaking, it's not the LPAR that you activate, it's the partition profile. This partition profile contains all the settings you need for your LPAR, including memory and processor allocation and any I/O slots you may require. By placing a set of partition profiles into a system profile, you can validate resource allocations to alert you to any potential conflicting demands on resources when you activate those partition profiles. You can also use system profiles to specify the startup order of LPARs following a system outage.

You can create a system profile using the HMC and then select some partition profiles to belong to that system profile.

How to create a system profile

To create a system profile using the HMC graphical user interface (GUI), complete the following steps:

  1. Select Systems Management.
  2. Click Servers.
  3. In the work pane, select the managed system.
  4. Click the Tasks button.
  5. Click Configuration.
  6. Select Manage System Profiles.
  7. Click Actions.
  8. Click New.
  9. Enter the name of the new system profile in System profile name.
  10. Select each LPAR that has a profile you want to add to the system profile; select that profile; and click Add.

    Note that you cannot include LPARs that use shared memory in system profiles.

  11. Click OK.

You can also use these menus to review existing system profiles. You can add or remove partition profiles or reorder the partition profiles that belong to a system profile. When you activate a system profile, the managed system attempts to activate the partition profiles in the order that they are listed in the system profile. The system profiles don't have to include all partition profiles, and you can always activate a single LPAR without using system profiles. If you delete a system profile, it doesn't remove the partition profiles that belonged to it.

Specify the startup order of your LPARs

System profiles let you activate a group of LPARs, and you can activate them in the order they appear in the system profile. This is important for managing dependencies. There are many ways you can design your system profiles.

One simple option is to put all your partition profiles in a single system profile so that you only have to activate the one system profile—instead of each partition profile, one by one. For example, suppose you have two VIOS and all your other LPARs are VIO clients. Among the VIO clients, you have some database LPARs and some application servers that depend on the database LPARs to be up and running. Here's how that dependency scenario looks:

  1. VIOS
  2. Database LPARs
  3. Application server LPARs

And that's the order they should appear in your system profile. With a little bit of thought and barely any effort, you have a ready-made startup order—and it's all documented on the HMC.

There are many other ways to group partition profiles into system profiles.

Scenarios for system profiles

The concept of system profiles is simple. After you work through a good plan for how you want to group your LPARs for activation, you can create a system profile and add the partition profiles in the order you need.

You don't need to restrict your configuration to a single system profile. You can group profiles quite differently. The following are a few ideas of how you might do that.

Create separate system profiles for production and non-production

You can create one system profile for production LPARs and another system profile for non-production LPARs. When it's time to start them all, select the production group first and activate it. The LPARs should start in sequential order within the group (for example, VIOS, then database LPARs, then application servers). If you do it this way, you can guarantee that the critical production LPARs get first pick of the desired resources that you set in their profiles.

Group your LPARs by application or function

If you're managing more than a handful of LPARs, you can group your LPARs according to how they work together for a particular application. If you're only interested in starting the LPARs that run SAP, for instance, you can create a SAP group and activate that.

Group your LPARs by business unit

If a set of logical partitions is used by only one business unit, it might make sense to put all those LPARs in a single system profile. That way the LPARs for more time-critical business users (such as the people who do the payroll) can be activated quickly, while you're working on starting up the others.

Business recovery service center

If you're administering a server for a business recovery service center, you might have a different client come in each week to use the same hardware as the previous client but with a completely different logical partition configuration. This is where system profiles are particularly handy. You can completely reconfigure the server for a new client's requirements by simply activating the system profile for that client. See Related topics for a working example of this.

Conflict resolution

One key benefit of system profiles is that you can use them to validate resource allocations in partition profiles. Validation of a system profile reports resource conflicts, for example if two LPARs both have an adapter as required, or if the total desired memory exceeds the amount available for partition usage. LPAR profile validation gives simple, clear messages about I/O, memory, and processor unit conflicts. It's an easy way to find out about possible resource shortages ahead of time rather than when you need to activate the profiles.

After you create a system profile, you can select it via the HMC GUI and click Validate to verify that there are no resource conflicts between the partition profiles that belong to it. You will get messages such as the ones shown below in Listing 1.

Listing 1. HMC validation messages
The following messages pertain to whether the system profile can activate 
if nothing else in the system is running:
There is no processor resource conflict within the system profile.
There is no memory resource conflict within the system profile.
There are 261376 Mb of total memory in the system, and the system profile 
will take an approximate minimum of 68096 Mb of that memory for activation.
There is no I/O resource conflict within the system profile.

System Profile Validation warnings:
Currently, even though partition db1's profile, db1_default, has a desired 
memory amount of 65536 Mb, it will only receive 21248 Mb of memory. It 
will not get its desired amount of memory, but it should still have 
enough to activate.
Currently, even though partition db1's profile, db1_default, has a desired 
processor unit amount of 1.0, it will only receive 0.3 processor units. It 
will not get its desired amount of processor units, but should still have 
enough to activate.


As you can see, creating system profiles is a simple and smart way of grouping LPAR profiles together. A single LPAR can have one or several partition profiles. And a partition profile can belong to more than one system profile. When you're dealing with dozens or maybe hundreds of LPARs, you want to minimize the time it takes to start them. System profiles also let you ensure that two LPARs are not competing for ownership of the same dedicated resources.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=AIX and UNIX
ArticleTitle=Manage LPAR startup order and validate resource allocation with system profiles