Micropartitioning and Its Effect on PVU Counts

Micropartitioning lets a single physical core be shared across many logical partitions in fractions. It is a powerful efficiency tool and a frequent source of PVU disputes, because how IBM counts a fractional partition is not obvious. Capped and uncapped partitions can produce very different numbers.

What micropartitioning does to the count

On platforms like IBM Power, micropartitioning carves physical cores into fractional virtual processors that partitions draw on. The appeal is density: many workloads share a small pool of cores. For PVU, the question becomes how many cores IBM treats the software as entitled to use, and that depends on how the partition is configured and what limits are enforced.

Capped versus uncapped

A capped partition cannot exceed its assigned processing entitlement, so the cores available to the IBM software are bounded by that cap. An uncapped partition can borrow idle capacity from the shared pool up to the number of virtual processors defined, so the count can rise to that ceiling rather than the nominal entitlement. The practical effect is that an uncapped partition often counts more cores than teams expect, because IBM counts the maximum the software could use, not the average it did use.

• Capped partition: the count is bounded by the assigned entitlement.
• Uncapped partition: the count can reach the defined virtual processor ceiling in the shared pool.
• Rounding: fractional results are resolved upward to whole cores in IBM's counting, so small fractions still cost a core.

Why this matters for sub-capacity

Micropartitioning only produces a low PVU number if the sub-capacity claim is valid. That requires an approved tool measuring the virtual cores, deployed within 90 days, running continuously, with quarterly reports retained for two years. Without that, IBM ignores the partitioning entirely and charges full-capacity on the whole physical host, which erases every efficiency the micropartitioning was meant to deliver.

Defending a micropartitioned estate

The defensible position rests on configuration evidence: the partition definitions, the cap settings, the virtual processor ceilings, and the continuous tool data that shows what the software was actually entitled to use. Disputes here are usually about whether an uncapped ceiling was counted correctly and whether the sub-capacity conditions were met for the period in question. Both are answerable with the right records.