AIX PVU vs IBM i P-Group Pricing
IBM Power runs two distinct licensing logics. AIX uses the Processor Value Unit model: a PVU-per-core rating set by the POWER generation, multiplied by the cores the software counts. IBM i instead uses processor-group (P-group) pricing — systems fall into tiers such as P05, P10, P20, P30 based on processor count and class, with price stepping up by group. The two models reward different optimisations: AIX rewards reducing counted cores, while IBM i rewards keeping a system within a lower processor group.
Because POWER generations carry different PVU ratings, a hardware refresh changes your AIX entitlement requirement even at identical core counts — a fact that makes refresh the natural moment to rebaseline rather than simply carry the old entitlement forward.
| Aspect | AIX | IBM i |
|---|---|---|
| Licensing metric | PVU per core (by POWER generation) | Processor-group (P05/P10/P20/P30) |
| Primary cost lever | Reduce counted cores via hard caps | Stay within a lower processor group |
| Sub-core entitlement | Micropartitioning (allocated units) | Tier-based, less granular |
| Subscription status | Moving to subscription | P20/P30 perpetual withdrawn Jan 2026 |
Micropartitioning and Entitlement Counting
The defining Power lever is micropartitioning — PowerVM's ability to allocate fractional, sub-core processor entitlements to a partition. Critically, AIX counts the allocated processor entitlement, not the whole physical core. A partition assigned 2.5 processing units is licensed against 2.5, not the 4 physical cores it may be able to burst into, provided the entitlement is enforced. This is the mechanism that makes Power sub-capacity materially cheaper than naive per-socket counting — but only when entitlements are set deliberately and capped.
Sub-Capacity on Power: Caps and ILMT
Sub-capacity on Power follows the same conditional logic as the rest of the IBM estate: it requires eligible technology and an approved tracking tool, and IBM's audit teams scrutinise Power sub-capacity intensely because misconfiguration is common and financially material. A partition that is uncapped, or capped soft, exposes you to counting against the higher of the cap or the observed peak. Enforcing hard caps and keeping ILMT current — exactly as set out in our ILMT configuration guide — is what protects the entitlement you designed.
On Power, the gap between allocated entitlement and physical capacity is where both the savings and the audit risk live. Design partitions to the workload, cap them hard, and prove it with ILMT — or IBM will count the cores you could have used, not the ones you did.
Rebaseline at Refresh: 10-30% Reduction
Entitlement counts drift upward over years of incremental change, leaving organisations licensed for capacity no live workload uses. A structured rebaseline at hardware refresh or renewal typically removes 10 to 30% of entitlement without any service impact — pure waste that accumulated through project-by-project additions. Refresh is the ideal moment because the POWER generation change already forces an entitlement recalculation; doing it deliberately captures the reduction rather than carrying old numbers forward.
Case Study: 40% Reduction via LPAR Caps
A representative review of a Power estate found a client running 120 cores across four POWER10 systems with peak concurrent usage that never exceeded 68 cores. By reconfiguring LPARs to enforce hard core limits totalling 72 cores, the organisation reduced its AIX and IBM i licensing obligations by 40% — roughly USD 480,000 in annual savings — with no impact on service levels. The saving came entirely from aligning entitlement to real demand, not from any negotiated discount. It is the clearest illustration that on Power, configuration is the negotiation.
The IBM i Subscription Shift
IBM is moving IBM i toward subscription, and it withdrew perpetual P20 and P30 operating-system licences effective 1 January 2026, with migration orders required by 31 December 2025. This reshapes the IBM i cost model from a capital purchase to a recurring term commitment and removes the perpetual fallback at renewal — the full economics, including the ELP anchoring trap, are covered in our subscription migration guide. Power buyers should treat the subscription transition and the licensing optimisation above as a single decision, sequenced so you rebaseline before converting and never subscribe to entitlement you do not need.
To model your Power position across capping, rebaselining, and subscription, request a confidential briefing or start with the IBM master guide.
Negotiating Power Hardware and Software Together
Power is one of the few IBM estates where hardware and software are negotiated in the same room, and that creates leverage most buyers leave unused. Processor cores on Power ship as activation features — you pay to light up capacity — and Capacity on Demand lets you activate cores permanently or elastically. Every activated core is also a licensing event for AIX, IBM i, and PowerVM, so the hardware configuration and the software bill are inseparable. Buy more activations than the workload needs and you pay twice: once for the hardware feature and again, every year, for the software entitlement that follows it.
At a refresh, sequence the negotiation deliberately. Rebaseline entitlement to real demand first, then size activations to the rebaselined figure, then trade hardware spend for software concessions — IBM account teams protecting a hardware deal will often move further on AIX, IBM i, and SWMA maintenance than they would in a software-only conversation. Use elastic Capacity on Demand for genuine peaks rather than permanently activating cores you need a few days a year. Negotiated this way, a Power refresh becomes a cost-reduction event rather than the entitlement-inflating exercise it usually is.
This guide is one of eleven in our IBM licensing cluster. To connect Power licensing to the rest of your IBM estate, read it with the IBM master guide, ELA negotiation, Passport Advantage, sub-capacity PVU counting, ILMT configuration, Db2 cost reduction, Cloud Paks licensing, watsonx pricing, mainframe MLC and zIIP, and subscription migration.
A further lever sits in PowerVM's shared processor pools. By placing several partitions in a capped shared pool, you can license against the pool's ceiling rather than the sum of individual partition peaks, which on a busy frame meaningfully reduces counted entitlement. On IBM i, the equivalent move is active management of the processor group: a system sitting just inside a higher P-group pays the higher tier across the board, so consolidating or splitting workloads to drop a tier can remove the licence step-change entirely. Both techniques reward treating partition layout as a financial decision, reviewed at every refresh, rather than a purely technical one. The configuration the infrastructure team chooses is, in effect, the price the business pays, so the two teams should make that choice together. Capacity on Demand activations follow the same rule: temporary or trial activations that are never deactivated quietly become permanent licence obligations, so a quarterly review of active versus needed cores keeps the entitlement honest and the bill aligned to real demand.
Where Power Licensing Fits
Power sits between the distributed world of PVU counting and the subscription shift now sweeping IBM, and it shares the Passport Advantage commercial backbone described in our Passport Advantage guide. It is distinct from the mainframe MLC world and from consumption platforms like watsonx. Read it alongside the IBM ELA negotiation guide, the IBM vendor hub, and the IBM Licensing Guide white paper.