IBM Power Systems Licensing:
AIX, IBM i & Linux on Power

IBM Power Systems Licensing: Why It Catches Enterprises Off Guard

IBM Power Systems licensing operates on a fundamentally different model from most enterprise software platforms. While x86-based infrastructure typically uses per-core or per-socket licensing, IBM Power Systems introduces processor-based licensing that varies by operating system, virtualisation technology, and partition configuration. In our experience across more than 500 IBM licensing engagements, IBM Power Systems is consistently where enterprises carry the largest unidentified licence gap — often exceeding $2M in exposure before any formal audit begins.

The challenge is not simply technical complexity: it is that IBM's licensing rules for AIX, IBM i, and Linux on Power each follow separate frameworks that interact in non-obvious ways when mixed on the same physical server. A POWER10 system running all three operating systems in separate LPARs (Logical Partitions) carries three distinct licence obligations — each calculated differently. Enterprises that manage these positions with spreadsheets rather than IBM's IBM Licence Metric Tool (ILMT) are particularly exposed.

IBM's Software Group conducts IBM Power audits through its Software Compliance and Audit Management (SCAM) programme. Unlike Oracle's LMS or Microsoft's licence review teams, IBM auditors frequently approach Power Systems with a deep technical knowledge of firmware-level data from IBM's own Hardware Management Console (HMC). Enterprises that underestimate this technical sophistication consistently face larger settlement demands.

AIX Licensing: Per-Processor Rules and Virtualisation Traps

AIX licensing is sold per processor on the physical IBM Power server. IBM counts the number of activated processor cores — not the number of LPARs consuming those cores — when calculating AIX licence requirements. This creates a specific trap: an enterprise might deploy AIX in two small LPARs using only 4 cores out of a 24-core POWER10 system, but IBM's position is that all 24 activated cores require AIX entitlement unless the remaining cores run only Linux (and are properly configured under PowerVM).

Processor Core Factor Table and POWER10 Complexity

IBM's Processor Value Unit (PVU) table assigns a PVU value per core depending on the processor generation. POWER10 cores carry 120 PVUs per core. A 16-core POWER10 system therefore requires 1,920 PVUs of AIX entitlement — or approximately $60,000 to $120,000 in annual maintenance fees depending on the AIX edition and support level. Managing this through IBM sub-capacity PVU licensing is one of the most common optimisation routes our advisors implement, potentially reducing that obligation by 30–60% depending on LPAR utilisation.

PowerVM's Capacity on Demand (CoD) feature adds another dimension of risk. When a CoD processor is activated — even temporarily — IBM's HMC records the activation. If the enterprise cannot demonstrate that this activation was for a defined CoD period rather than permanent use, IBM treats the processor as permanently licensed. Enterprises must maintain meticulous HMC records alongside ILMT data to defend against this position.

IBM i (iSeries) Licensing: Processor-Based Pricing and P-Group Tiers

IBM i — the operating system formerly known as OS/400 and i5/OS — uses a processor group (P-Group) pricing model that differs from both AIX's PVU model and Linux sub-capacity rules. IBM i is priced by processor tier: P05, P10, P20, P30 up to P50 for high-end systems. Each tier carries a higher per-system or per-processor-group price, with P50 licences for large POWER10 configurations routinely reaching £500,000 to £1.5M for a single system.

IBM i licensing applies to the entire active processor capacity of the partition running IBM i — it cannot be sub-capacity licensed in the same way as LPP products on AIX. This means enterprises with IBM i in an LPAR alongside other workloads must carefully design their LPAR topology to isolate IBM i on the minimum processor resources required, and ensure those processor allocations are reflected correctly in the HMC configuration before any IBM audit snapshot is taken.

Many enterprises running IBM i on Power have not recertified their processor group assignment since migrating from POWER7 or POWER8 hardware. A move to newer, higher-core POWER10 systems without re-evaluating the P-Group tier frequently results in under-licensing. IBM's audit team checks the current hardware configuration against the P-Group assigned in the licence and software inventory, and discrepancies of two or three tiers are common — each tier jump representing a six-figure incremental obligation. Download our IBM licensing complexity guide for a framework on P-Group tier assessment.

Linux on Power: Sub-Capacity and RHEL Licensing Rules

Linux on IBM Power is licensed under IBM's sub-capacity rules — specifically when using Red Hat Enterprise Linux (RHEL) on Power under IBM's RHEL subscription model, or when deploying IBM software on Linux LPARs. Sub-capacity licensing allows enterprises to licence IBM software based on the PVU capacity allocated to an LPAR rather than the full physical server, provided ILMT is correctly installed and reporting.

The interaction between IBM's sub-capacity rules and RHEL's own subscription model creates one of the more complex licence positions in enterprise IT. IBM requires ILMT to capture sub-capacity measurements for IBM software running on Linux LPARs. If ILMT is not deployed — or if its configuration does not meet IBM's sub-capacity eligibility criteria — IBM defaults to full-capacity pricing for the entire physical server. In practical terms, this converts a £200,000 sub-capacity licence obligation into a £600,000 to £1.2M full-capacity obligation overnight.

Our IBM licensing team regularly finds that enterprises have ILMT installed but misconfigured: disconnected agents, gaps in scanning schedules, or missing LPAR entries. These gaps invalidate sub-capacity eligibility for the affected products. Working with our IBM licence assessment tools, we identify these gaps before an IBM auditor does and remediate them in a way that protects the sub-capacity position.

LPAR Management and PowerVM: Optimisation and Compliance

IBM's PowerVM hypervisor is the virtualisation layer on all POWER systems. Logical Partitions (LPARs) under PowerVM can be configured as dedicated-processor partitions or shared-processor partitions — and this distinction has significant licensing implications. Dedicated-processor LPARs commit specific processor cores exclusively to that partition; shared-processor LPARs draw from a shared pool, consuming a fractional entitlement measured in virtual processors.

For AIX sub-capacity licensing, IBM requires the LPAR to be configured as a capped shared-processor partition. Uncapped partitions — where the LPAR can burst above its entitled processor capacity — do not qualify for sub-capacity licensing under IBM's rules. Many Power Systems administrators configure LPARs as uncapped for performance reasons without realising this invalidates sub-capacity eligibility. When IBM's HMC data shows uncapped partitions, IBM's auditors calculate full server-level PVU exposure rather than LPAR-level sub-capacity.

The IBM Db2 database — commonly deployed on Power Systems alongside AIX or Linux — has its own PVU-based licence requirements that interact with PowerVM LPAR configuration. See our IBM Db2 licensing guide for detailed analysis of how Db2 on Power Systems should be correctly licensed and how to avoid double-counting between OS-level and middleware-level PVU obligations. Similarly, IBM MQ and WebSphere licensing on Power Systems frequently generates audit findings due to incorrect LPAR configuration.

To reduce IBM Power licensing costs, Redress advisors recommend three primary approaches: first, audit all LPAR configurations and convert uncapped partitions to capped where operationally feasible; second, consolidate underutilised LPARs to reduce the total activated processor count; third, engage IBM in a structured licence review before any formal audit commences — enterprises that proactively remediate positions consistently achieve better commercial outcomes than those responding to IBM-initiated audits. To discuss your specific Power Systems estate, book a confidential call with our IBM advisory team.