AIX WPAR and Sub-Capacity Eligibility
A WPAR is a workload partition that lives inside an AIX LPAR, and that nesting is where the licensing question sits. Whether IBM counts the WPAR boundary, the surrounding LPAR, or the whole frame depends on the WPAR type and on what your reporting tool can actually see. The boundary you can prove is the boundary you pay for.
WPARs live inside an LPAR
On Power, the LPAR is the partition the operating system runs in, and a WPAR is a lighter partition created within that AIX instance. For sub-capacity the relevant question is how many cores are available to the IBM software, and that depends on where the software runs in the stack. A WPAR cannot escape its parent LPAR, so the cores available to it are bounded by the LPAR, which is bounded in turn by the frame.
System WPAR and the parent LPAR
Because the WPAR is constrained by its parent, the LPAR configuration usually drives the countable cores. If the IBM software runs in a WPAR inside a capped LPAR, the cap on that LPAR is the natural ceiling for the count, provided the configuration is correct and the reporting tool reflects it. The trap is assuming the WPAR shrinks the number on its own: it is the LPAR boundary, properly capped and measured, that delivers the smaller figure.
- WPAR inside a capped LPAR: the LPAR cap bounds the countable cores when evidenced
- WPAR inside an uncapped LPAR: measured against the cores the LPAR can consume
- Tooling that cannot see the WPAR: risks defaulting to the LPAR or frame total
- Misread nesting: a frequent cause of an inflated finding
Eligibility still depends on ILMT
AIX and Power are eligible virtualization technologies, but eligibility is conditional. The sub-capacity claim requires ILMT, or an approved tool, deployed within 90 days of first eligible deployment, running continuously, with quarterly reports retained for two years. If ILMT cannot resolve the WPAR and LPAR relationship correctly, it may miscategorize the install, and a miscategorized install needs manual correction. Left uncorrected, a reporting tool that cannot see the real boundary leaves IBM free to charge against the larger one.
How buyers defend it
We map the WPAR to LPAR to frame relationship for each deployment, confirm the parent LPAR caps are configured as intended, and verify that ILMT recorded the correct partition boundary across the lookback. Where a finding counts the full LPAR or frame against a WPAR confined workload, the counter is the configuration evidence plus the continuous reports that show the cores actually available to the software. Where ILMT miscategorized the install, we correct it and rebuild the defensible number.
A WPAR does not reduce the count by itself, the capped LPAR around it does. Confirm the parent LPAR boundary, make sure ILMT resolves the nesting correctly, and keep the quarterly reports so the available cores are documented. If the reporting tool cannot see the WPAR boundary, IBM will count the LPAR or the frame, and on Power that is the expensive default you most want to avoid.