IBM Power Systems AIX Licensing: A Complete Advisory for Enterprise Teams

AIX Licensing Fundamentals

IBM AIX — IBM's proprietary Unix operating system — runs exclusively on IBM Power Systems hardware. Unlike most modern software, AIX is licensed through a Software Maintenance Agreement (SWMA) tied to the hardware serial number of the specific Power server on which it is installed. This serial-number-based model has important implications for hardware refresh cycles, LPAR configurations, and virtualised deployments.

The SWMA covers the AIX operating system licence, future versions and updates, and technical support. There are no separate user access licences or concurrent user limits for AIX itself — but the middleware and applications running on top of AIX almost universally carry their own separate IBM software licences, typically measured in Processor Value Units (PVUs) or Virtual Processor Cores (VPCs). It is this middleware licensing layer, not AIX itself, where the majority of enterprise compliance exposure resides.

AIX Subscription Licensing Options

IBM has expanded the AIX licensing model to include subscription-based options alongside the traditional perpetual SWMA. IBM now offers subscription licences valid for one-year or three-year terms covering AIX Standard Edition, AIX Enterprise Edition, and AIX Enterprise Cloud Edition. For organisations migrating workloads to IBM Power Virtual Server in the cloud, the subscription model provides more flexibility than serial-number-bound perpetual licences.

The distinction between the three AIX editions matters primarily for enterprises running AI, analytics, or containerised workloads on Power infrastructure. Enterprise Edition includes additional capabilities relevant to these workloads. The licensing cost difference between editions can be significant at scale, making edition selection a meaningful negotiating point during Power hardware procurement.

LPAR Sub-Capacity Licensing: The Highest-Value Compliance Topic

IBM Power Systems support Logical Partition (LPAR) virtualisation through PowerVM. LPARs allow a single physical Power server to be divided into multiple isolated virtual environments, each running its own operating system and workloads. The licensing treatment of IBM middleware software running within LPARs is where enterprise compliance risk is most concentrated.

Full Capacity vs Sub-Capacity Licensing

Under IBM's full-capacity model, every IBM software product installed on a Power server must be licensed for all processor cores on that physical server — regardless of how many cores are actually allocated to the LPAR running that software. For a 16-core Power server running one LPAR with 4 cores allocated to IBM middleware, full-capacity licensing requires 16 cores' worth of licences.

Sub-capacity licensing is IBM's alternative for virtualised environments. Under sub-capacity rules, you only licence IBM middleware for the processor cores assigned to the LPAR where that software runs — in our example, 4 cores rather than 16. The cost difference is typically ten to twenty times in favour of sub-capacity. However, sub-capacity eligibility is conditional on meeting IBM's technical and administrative requirements — and those requirements are non-negotiable.

Sub-Capacity Requirements

To qualify for sub-capacity licensing on IBM Power Systems, three conditions must be met without exception. First, the software product must be eligible for sub-capacity licensing under IBM's programme — not all IBM software qualifies. Second, ILMT (IBM License Metric Tool) must be correctly installed and configured across the entire virtualised environment. Third, ILMT must be actively generating and retaining audit snapshot reports at the required frequency. If any of these conditions is not met, IBM treats the deployment as full-capacity for the entire historical period — not just from the date non-compliance was discovered.

ILMT on Power Systems: What Gets Missed

IBM License Metric Tool (ILMT) is the mandatory measurement tool for sub-capacity compliance. On IBM Power Systems running AIX, ILMT must be deployed as an agent on every LPAR where IBM sub-capacity eligible software runs, and as a server component to aggregate and report usage data. ILMT then generates quarter-end audit snapshots that document the maximum processor core allocation to IBM software during that quarter.

Common ILMT Failures on Power

From our IBM audit defence work, the most common ILMT failures on Power Systems environments are: incomplete agent deployment (ILMT agents missing from some LPARs because they were created after the initial ILMT deployment project and never added to the managed scope), outdated software catalogues (ILMT uses a catalogue to recognise IBM software — an outdated catalogue means software goes unrecognised and unreported), and retention failures (IBM requires audit snapshots to be retained for at least two years — snapshots deleted during system migrations or storage clean-ups create compliance gaps that IBM back-charges to the earliest un-documented period).

A particular risk on Power Systems is the processor pool interaction with sub-capacity counting. If LPARs are configured to share a processor pool and can draw from any core in that pool dynamically, ILMT must track the maximum concurrently used cores across the pool — not just the allocated minimum. Enterprises that configure dynamic processor sharing without understanding the sub-capacity accounting implications regularly find themselves with higher-than-expected licence obligations when ILMT reports are reviewed.

The PVU to VPC Transition and Power Systems

Processor Value Units (PVUs) have been IBM's primary software licensing metric for distributed and Power-based workloads for many years. A PVU is a weighted unit that reflects the relative processing power of different processor types and generations — IBM Power processors carry specific PVU-per-core ratings that determine the licensing cost per core.

Virtual Processor Cores (VPCs) are IBM's newer metric, increasingly used for Cloud Pak products and containerised workloads. Where PVUs account for processor type and physical architecture, VPCs are a flat metric — one VPC equals one virtual CPU core regardless of the underlying hardware. For Power System users moving workloads to containerised environments or IBM Cloud Pak deployments on OpenShift, the transition from PVU to VPC licensing is a key cost and compliance consideration.

PVU to VPC: Cost and Compliance Implications

The PVU to VPC transition created compliance gaps for enterprises that migrated IBM software from traditional LPAR environments (PVU-licensed) to containerised environments (VPC-licensed) without properly documenting the transition, updating their ILMT configuration to use IBM License Service for container measurement, and ensuring both measurement systems were generating accurate reports during any overlap period. IBM does not automatically credit PVU licences against VPC requirements — they are different metrics under different parts of the Passport Advantage Agreement.

For Power-specific deployments, IBM provides conversion ratios to facilitate PVU-to-Cloud Pak transitions (approximately 1 PVU = 1 VPC for conversion purposes), but these conversions must be explicitly executed through IBM's Passport Advantage transaction system. Enterprises that assume informal equivalence without formal conversion create a licence deficit that IBM can assert during audit.

POWER10 Software Tier Licensing

IBM's current generation Power platform — POWER10 — introduced a structured software tier model that affects IBM i and AIX-adjacent middleware licensing. Different POWER10 machine configurations are assigned to software tiers (P05, P10, P20, P30) based on their processing capacity, and these tiers determine the base software licence cost for tier-priced IBM products.

On 7 May 2024, IBM announced that customers purchasing specific Power10-based P05 and P10 software tier machines must adopt subscription licensing rather than perpetual licences. Perpetual OS licences for these tiers were withdrawn from that date. This subscription mandate applies to IBM i on the relevant Power10 systems, and represents IBM's broader push toward subscription-based consumption models across its infrastructure software portfolio.

For enterprises managing hardware refresh cycles, understanding the licensing tier of new Power10 systems at the point of procurement is essential. A hardware upgrade that moves a workload from a P10-tier to a P20-tier machine can increase software licence costs significantly, and this cost increase is rarely highlighted by IBM during hardware sales discussions.

Oracle Licensing on IBM Power Systems: A Special Caution

A frequent complication in Power Systems licensing reviews is the interaction with Oracle software. Oracle's hard partition policy differs significantly from IBM's sub-capacity approach — Oracle generally requires full processor licensing for Oracle software on IBM Power servers unless the LPAR is configured as a "hard partition" meeting Oracle's specific technical requirements. IBM's sub-capacity rules and ILMT have no effect on Oracle licensing obligations.

Enterprises running Oracle software on IBM Power infrastructure need separate Oracle licensing analysis alongside their IBM compliance review. Conflating IBM sub-capacity logic with Oracle licensing requirements is a common and potentially costly mistake.

Audit Risk Factors on IBM Power Systems

IBM Power Systems environments carry above-average audit risk for several structural reasons. Power infrastructure is typically long-lived — servers run for five to ten years, during which LPAR configurations change, new software is deployed, and ILMT may be inconsistently maintained. IBM's audit team understands this lifecycle pattern and targets Power environments that show signs of configuration drift or ILMT gaps.

Specific audit trigger conditions that Redress Compliance has observed in IBM Power audit situations include: hardware upgrades from older Power generations to POWER9 or POWER10 without corresponding licence reviews, ILMT snapshot retention gaps coinciding with storage migrations or ILMT version upgrades, dynamic processor pool configurations where ILMT tracking lapsed during system changes, and transitions from AIX to Linux on Power where some IBM middleware continued running on the AIX side without proper licence accounting.

What to Do Before Your Next IBM Audit

Proactive preparation is far more cost-effective than reactive audit defence. For IBM Power Systems environments, a pre-audit review should cover four areas. First, verify that ILMT agents are installed on every LPAR where IBM sub-capacity eligible software runs, and that the ILMT software catalogue is current. Second, confirm that two years of quarterly ILMT audit snapshots are retained and accessible. Third, review processor pool configurations to ensure ILMT is correctly accounting for dynamic core allocation. Fourth, reconcile your PVU entitlements against current ILMT reports and identify any gaps before IBM does.

If you have already received an IBM audit notice covering Power Systems deployments, engage independent IBM licensing expertise before responding. The characterisation of LPAR configurations, the validity of sub-capacity claims, and the appropriate audit period scope are all negotiable positions that require specialist knowledge to defend effectively.