RHEL on IBM Power, counted by the partition.

RHEL on IBM Power runs under the PowerVM hypervisor, which divides the physical Power host into logical partitions. Each logical partition presents to the operating system as an independent server with its own processor and memory allocation. RHEL on Power is licensed per partition, with the entitlement sized to the processor units assigned to the partition under PowerVM. The counting unit is the logical partition, not the physical host; a single Power host carrying eight partitions consumes eight RHEL on Power entitlements, with each entitlement sized to the processor allocation of the partition it covers.1

The Intel side of the same RHEL estate uses a different counting unit. On Intel hardware, the RHEL subscription is priced per socket pair on the physical host, with the Virtual Datacenter variant providing unlimited guest coverage on a registered hypervisor. The Power counting unit has no Virtual Datacenter equivalent; the partition is the unit, and the partition is counted regardless of whether it is the only partition on the host or one of many. The reading on the Intel side sits in the RHEL Virtual Datacenter deep dive; the Power side has its own discipline and the procurement register should reflect both separately.

The audit ready artifact on the Power side is the Hardware Management Console partition list. The HMC owns the inventory of every active partition across the Power estate, the processor entitlement on each partition, and the partition lifecycle history including suspended and shut down partitions. The procurement register is read against the HMC inventory; the reading is internally consistent when every active partition carries a paid RHEL on Power line at the right processor size.

Three counting traps recur on RHEL on Power readings. Each is structural; each remediates inside a renewal cycle.

The first trap is the dormant partition. A partition is configured on the Power host, the partition profile exists in the HMC, the partition is currently in shut down or suspended state, and the procurement register continues to carry a line for the partition. The reading on the dormant partition depends on the catalogue terms; some catalogue revisions treat the dormant partition as exempt while it is in shut down state, while others treat it as in scope for the period of configuration. The practice has settled this pattern by treating the partition as in scope while the partition profile exists in the HMC and is capable of activation; the safer reading is to size the entitlement to the active partitions and to confirm the catalogue treatment with the procurement team before retiring lines for dormant partitions.2

The second trap is the capacity on demand activation. The Power host carries processor capacity that the IBM capacity on demand programme activates on demand; the partition expands into the activated capacity as the workload requires; the procurement register carries the entitlement at the base capacity sizing, not the activated capacity. The reading is exposure on the differential between the base and the activated capacity for the period of activation. The remediation is to size the entitlement to the peak activated capacity at each renewal cycle and to attach additional lines where the activated peak persists.

The third trap is the parallel Intel reading. The buyer's procurement register treats the RHEL estate as a single line item, the Power partitions are counted alongside the Intel hosts on the same socket pair basis, and the per partition entitlement on the Power side is materially under counted. The remediation is to split the procurement register between the two counting units and to reconcile each unit against its own audit ready artifact. The pattern is structurally identical to the parallel line readings walked in the High Availability add on note; the counting unit is the source of the drift on the Power side, not the line type.

SAP HANA on IBM Power runs on the certified Power platform with its own variant of the RHEL for SAP HANA subscription. The HANA on Power line is sized to the partition rather than the physical host, and the memory tier pricing discussed in RHEL for SAP HANA licensing applies on a per partition basis. A scale out HANA cluster running on Power partitions across one or more physical hosts carries one HANA on Power line per partition, sized to the memory and processor allocation of each partition.

The reading interacts with the broader SAP estate on Intel. Most SAP estates that include Power for the HANA database tier also include Intel for the application server tier; the procurement register should reflect both lines, with the HANA on Power line on the database side and the SAP Applications line on the application side. The cross tier reading sits in the SAP Applications note. The bundled cluster stack on the HANA on Power line carries the same structural property as on the Intel side; a parallel High Availability line on a HANA on Power partition is overpayment, not redundancy.

The reading also interacts with the broader IBM Z and LinuxONE topology discussed in the IBM Z and LinuxONE note, where a different counting unit again applies. The three IBM platforms each carry their own RHEL counting discipline; the procurement register that treats them as identical is a procurement register that will produce findings in audit. The cross industry reading on regulated audit exposure on Power estates sits in financial services audit considerations.3

The audit reading on RHEL on Power walks three data sources. The HMC partition inventory across the Power estate, the PowerVM processor allocation on each partition, and the procurement register of RHEL on Power lines by partition. The reading is internally consistent when every active partition carries a paid line at the right processor size and when the capacity on demand activation history has been reflected in the procurement register over the trailing twelve months.

Three inconsistencies recur. The first is the active partition without a paid line; the reading is exposure for the period of partition activation. The remediation is the attach at the next renewal and the retroactive treatment of the period of operation in any settlement reading. The second is the line at the wrong processor size; the partition has been resized through a PowerVM operation since the last procurement cycle, the line has not been resized to match, and the reading is exposure on the differential. The third is the line that persists for a retired partition; the reading is overpayment, and the remediation is the retirement at the renewal.

The reading also requires the capacity on demand activation log. The IBM capacity on demand programme retains the activation history on the HMC and on the broader IBM support records. The audit ready artifact is the HMC partition list joined with the capacity on demand activation log. The buyer's narrative about the workload pattern is not authoritative; the HMC is.4 The reading interacts with the broader audit defense treatment in audit defense.

The renewal posture on RHEL on Power has three habits. The habits are unglamorous; the same three habits, applied honestly, retire the recurring drift on most Power estates within a single renewal cycle.

The first habit is the HMC partition inventory of record. A short artifact, owned by the Power systems team and reviewed by the procurement team, that names every active partition across the Power estate, the processor allocation on each partition, and the line that covers it. The artifact is reviewed quarterly. The artifact sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the capacity on demand reconciliation. The capacity on demand activation log is reviewed at each renewal cycle, the peak activated capacity over the trailing twelve months is taken as the basis for the renewal cycle sizing, and the procurement register is updated to reflect the peak. The broader treatment overlaps with under entitlement audit exposure on the upward direction and with recoverable over entitlement cost on the downward direction.

The third habit is the split register discipline. The procurement register treats the Power side and the Intel side as separate sub registers, each reconciled against its own audit ready artifact, with no cross subsidy between the two. The cross subsidy is the source of the most expensive findings on mixed Intel and Power estates in the practice's observation. The broader treatment of renewal cycle discipline sits in renewal negotiation; the sibling treatment on the IBM Z platform sits in the IBM Z and LinuxONE note.

For the RHEL practice hub, see the RHEL practice. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.