Power Enterprise Pool Conversions

By STEPHANIE JENSEN posted Tue June 23, 2020 10:54 PM


I purchased a Power Enterprise Pool (PEP). My resources are Mobile-Enabled. How do I get my PEP running?

PEP pool structure

A Power Enterprise Pool which we will refer to as PEP in this blog entry, is at its simplest, a construct in which one HMC is connected to two or more Power Servers with Dark (Unlicensed) Procs and/or Memory. This PEP is given a certain number of floating Licenses that can be assigned by the user to any server in the pool at any time. All of this information (which servers, how many resources) is encoded into a text file, of the format XML, that is generated by IBM Manufacturing and posted for the customer to download and deploy.

high level pool layout

Since complete PEP definitions require the individual servers to be identified by System Serial Number, it is important to know that the System Serial Number is not known until actual server manufacturing occurs. This is significant because if a customer orders several servers and also orders a PEP construct across that set of servers, the complete deployment of a PEP to the customer cannot be finished until all the machines have been defined and manufactured. 

PRE-PEP staged delivery

For accounting purposes, the customer purchases PEP Processors ultimately for use across the pool, but each server in the pool has a subset of that number ordered in that server’s own purchase. Processors ordered for each server, but intended to be part of the set that can be moved from server to server, are called Mobile-Enabled Processors. The same applies to server memory, but for simplicity, we will just refer to the processors in this blog entry.  

(Reference Link: )

At manufacturing time, these Mobile-Enabled Processors are assigned to the given server as Permanent Processors, so the customer has immediate use of that portion of the resources as soon as that Server arrives at the customer site.

partially deployed PEP

In addition, some Power 7 server offerings previously included the ability to license processors on the Power 7 servers, and then when Power 8 servers arrived, those same Power 7 processor licenses would be  allowed to float to Power 8 servers in a PEP pool. These types of Power 7 PEP processors are also called Mobile-Enabled processors.  

Conversion of Mobile-Enabled resources

When all of the PEP servers arrive at the customer locations, the HMC XML file that contains that complete definition can then be deployed. Once this happens, PEP resources can be assigned by the HMC to any given server. A Mobile PEP resource assigned to a server converts a currently-Unlicensed processor to a Licensed processor. However, remember that if the server’s resources are all previously Mobile-Enabled, they are initially assigned to that server as Permanent Processors, and there may not be any Unlicensed processors yet. That leaves us with the problem of how to convert the Mobile-Enabled resources so they are able to participate in the PEP resource movements.


This scenario can be handled on one of two methods:

  1. Obtain a “Remove” License key from IBM, to “Un-License” the number of Mobile-Enabled Procs
  2. Obtain an XML file that additionally has direct Permanent-To-Mobile conversion keys for servers


The first method exists now for any PEP setup for any firmware level, but its main drawback is that it requires any Permanent Processor to be unassigned from any partition profile or use before it can become “Un-licensed” with a Remove key. If that can be accomplished, even for a short time, then the customer just needs to “Remove” the License from those processors, and then those resources can be assigned in by the HMC as PEP resources and go about their business again. This method works well, but it is disruptive to the customer’s workload if they have to quiesce some work to allow for Un-licensing a Permanent resource, even if it is for just a short time.


First method: Free resource, Unlicense it, wait for PEP Resource assignment when Pool is active

in-place 2 step conversion


The second method, that does NOT disrupt a customer’s workloads, exists as an available capability in Server Firmware FW840 as well as a newly-released Service Pack feature in Firmware FW780. With this additional capability, the XML file itself can initiate a conversion of a Permanent Processor to an assigned Mobile (PEP) Processor on the given server, in place, without the requirement that the customer free up the resource and “Remove” the Permanent License before assigning a PEP processor to it. This is a seamless conversion that has no effect on running workloads, so it is very convenient for the customer as part of the complete PEP deployment. In one step, the local Permanent resource is transitioned to a PEP resource and is considered “assigned” to this server by the HMC, with no disruption or awareness of this transaction to any customer workload.


Second method: Convert Perm Resource in place, directly to PEP Resource, no interruption

in-place 1 step conversion

Understanding the numbers

You may be wondering how this all adds up. If one takes away Permanent License from a server, for some number of processors, how are you not losing resources?  Remember that the PEP XML has the definition of how many Total PEP resources are entitled to be moved around for this pool, and that number is the sum of all the PEP Processors you purchased. Subsets of that total number were initially put on as Permanent Licenses on individual servers so you could use them immediately before total PEP deployment, but ultimately that number of Processors is to be sitting Un-licensed on the server until an HMC assigns a PEP resource to it. Therefore, the process of Un-licensing resources from the server is, in effect, just allowing the License to be managed by the HMC rather than being stuck on the server. The net effect is NO CHANGE to the number of entitled resource; you are just changing the state of the resources so the HMC can manage them directly with the PEP functionality rather than leaving the resources permanently assigned to that one server with no possibility of moving them elsewhere. Today, the #1 method exists as outlined above, and for certain firmware levels, the #2 method also now exists to make this transition even smoother. The #1 method certainly works, but it is more administrative-intensive in its requirements.

My situation is a little more complicated than that…

The scenarios described in the write-up here are generalizations and are used to illustrate the concepts that are at work when deploying a PEP configuration. There are always real-world situations in which the actual server deliveries are not all at the same time, and in which workloads are tied to machines that cannot take any disruptions in their existing production operations, and a myriad of other possibilities. 

If your situation does not fit comfortably in the generalizations described here, there may very well be alternate strategies that can be employed.

  • For example, if a server has Mobile-Enabled resources on it and has running workloads that cannot be disturbed, and furthermore cannot uptake the FW780 Service Pack or the FW840 level, perhaps the workload can be LPM’d (Logical Partition Mobility) to another server. Once the workload is off the server, then one can temporarily Un-license the processors, assign in PEP resources to the server, then bring the workload back again via LPM.
  • Another possible strategy is to use DLPAR to reduce the number of running resources from your partitions, leaving the partition temporarily running with the lesser capacity while the resources are Un-licensed via a key. Once they are un-licensed, assign them back again as PEP resources and use DLPAR again to restore the running resources to the desired levels.
  • A third possibility also can be seen. Rather than Mobile-Enabled, your servers may have come in with the intended PEP resources Un-licensed at all, with the expectation that complete delivery of the balance of the servers and ultimate PEP deployment would follow. Until that happened, you used Trial Capacity on Demand to temporarily license your resources, and now the PEP deployment is ready. In Server Firmware FW820 and FW830, the ability to assign PEP Resources on top of Trial resources does not exist; that is, you must end your trial and return all the resources (free them by removing them from any partition assignment or use) before you can assign in PEP resources. In FW840, and now in the newly-released FW780 Service Pack, you can allow the Trial to expire, leaving the resources still running but listed as “Unreturned”, and then satisfy that “Unreturned” state by assigning in PEP resources with the HMC.

These are just 3 possible real-world scenarios we have had to deal with in customer setups, but each unique scenario did have workable solutions to get the PEP deployment up and running. If your situation is not found in this list, you certainly can work with your Business Partner or your IBM contacts to get your situation understood and get a workable strategy in place to complete your PEP deployment.


Jump on into the PEP Pool!  The water is great!

Contacting the PowerVM Team

Have questions for the PowerVM team or want to learn more?  Follow our discussion group on LinkedIn IBM PowerVM

Last updated: September 12, 2016