RHEL on IBM Z and LinuxONE, priced by the IFL.

The IBM Z and LinuxONE mainframe platforms run Linux workloads on a specialty processor type called the Integrated Facility for Linux, or IFL. IFLs are physical processor cores on the mainframe that the IBM firmware reserves for Linux workloads; standard general purpose processors on the mainframe run z/OS and other traditional workloads, and the IFLs run Linux. Red Hat Enterprise Linux on Z and LinuxONE is licensed per IFL rather than per host, per socket pair, or per guest. The counting unit is the IFL, and the entitlement scales with the number of IFLs that host RHEL workloads on the mainframe.1

The mainframe topology runs RHEL under one of three configurations. The first is z/VM, the long established mainframe hypervisor that runs RHEL guests on shared IFL capacity. The second is KVM on Z, the more recent open source hypervisor option that runs RHEL guests under a KVM stack on IFL capacity. The third is direct PR/SM, the partition manager that hosts RHEL directly on a logical partition without an intermediate hypervisor. The counting unit is the IFL across all three configurations; the configuration does not change the counting, only the operational pattern.

The Intel side of the same RHEL estate uses a different unit, and the IBM Power side uses a third unit again. The discussion of the Intel side sits in the RHEL Virtual Datacenter deep dive; the Power side sits in RHEL on IBM Power licensing. The procurement register that aggregates the three platforms into a single line item under one counting unit is a procurement register that will produce findings on at least two of the three platforms.

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

The first trap is the IFL count that has drifted. The mainframe firmware records the number of IFLs activated at any moment; the activation can change as IBM capacity on demand programmes activate or deactivate IFL capacity through a billing cycle; the procurement register frequently carries a single count from a prior cycle. The reading is exposure where the activated count exceeds the procurement count and overpayment where the procurement count exceeds the activated count. The remediation is the resize at the next renewal, sized to the peak activated count across the trailing twelve months. The pattern parallels the capacity on demand drift on the Power side walked in RHEL on IBM Power licensing.2

The second trap is the guest count miscount. A buyer treats the RHEL on Z line as a per guest unit by analogy to the Intel guest reading; the procurement register carries one line per RHEL guest; the actual unit is the IFL and the cost is significantly over counted. The reading is overpayment, and the remediation is the resize to the IFL count at the next renewal. The savings on the resize are frequently material; the pattern is the most common overpayment finding on RHEL on Z readings in the practice's observation, and the buyer side reading frames the resize as a renewal opportunity rather than as an audit risk.

The third trap is the shared IFL pool drift. A buyer runs IFLs across multiple logical partitions on the same mainframe, with z/VM running RHEL guests on some partitions and KVM on Z running RHEL guests on others; the IFL pool is shared dynamically across partitions according to workload; the procurement register carries lines pinned to specific partitions rather than to the IFL pool. The reading is exposure where IFLs move to a partition with insufficient entitlement and overpayment where IFLs vacate a partition with surplus entitlement. The remediation is to size the entitlement to the total IFL pool across the mainframe, not to specific partitions, and to update the procurement register accordingly.

The three mainframe hosting configurations each carry their own operational characteristics; the entitlement counting is the same across all three. The buyer side reading should reflect the operational pattern in the host inventory but not in the entitlement count.

z/VM is the long established mainframe hypervisor. A z/VM partition hosts many RHEL guests on a shared IFL pool; the guest count varies as workloads move between partitions; the IFL pool is the constant. The procurement register carries lines sized to the IFL pool, not to the guest count. KVM on Z is the more recent open source hypervisor option. KVM on Z partitions host RHEL guests on shared IFL capacity with a familiar Linux operations model; the counting is again on the IFL, not the guest. The interaction with the broader virtualisation reading sits in the RHEL Virtual Datacenter deep dive.

Direct PR/SM is the configuration where RHEL runs directly on a logical partition without an intermediate hypervisor. The partition is sized to a specific IFL allocation; the RHEL operating system runs on the partition; the entitlement is sized to the IFL allocation of the partition. The configuration is less common than the hypervisor backed configurations but is the operational choice for very high throughput workloads where the hypervisor overhead is unwanted. The counting unit is the IFL across all three configurations. The operational choice between the three is independent of the entitlement reading, and the procurement register should not vary by hypervisor choice.3

The audit reading on RHEL on Z and LinuxONE walks three data sources. The mainframe IFL activation records as recorded by the IBM firmware, the partition and guest inventory across z/VM, KVM on Z, and direct PR/SM partitions, and the procurement register of RHEL on Z lines sized to the IFL count. The reading is internally consistent when the procurement count matches the peak IFL activation across the trailing twelve months and when no RHEL workload runs on an IFL outside the entitlement scope.

Three inconsistencies recur. The first is the unentitled IFL. The mainframe records show IFLs that ran RHEL workloads during a peak activation period; the procurement register did not extend to cover them; the reading is exposure for the activation period. The second is the surplus IFL line. The procurement register carries more IFL entitlement than the mainframe activated at peak; the reading is overpayment, and the remediation is the resize at renewal. The third is the workload outside the IFL scope. A RHEL workload that an engineering team migrated onto a general purpose processor for testing or for a temporary capacity reason; the workload appears on the mainframe but not on the IFL pool; the procurement register has no IFL line that covers it. The reading is procedurally awkward; the remediation is to confirm the workload returns to the IFL pool and to align the procurement register accordingly.

The mainframe audit reading interacts with the broader treatment of audit defense on regulated industries. A buyer with a mainframe estate typically operates in finserv, public sector, or government. The cross industry reading sits in financial services audit considerations and in the broader treatment of audit defense.4

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

The first habit is the IFL activation log. A short artifact, owned by the mainframe systems team and reviewed by the procurement team, that names every IFL across the mainframe estate, the activation state across the trailing twelve months, and the partition or workload the IFL hosts. The artifact is reviewed quarterly. The artifact sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the peak activation reconciliation. The procurement register is sized to the peak IFL activation across the trailing twelve months, not to the average and not to the steady state. The peak is the basis the audit reading will use, and the procurement register should match. The pattern overlaps with the broader treatment of 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 mainframe sub register is separated from the Intel and Power sub registers; each sub register is reconciled against its own audit ready artifact; no cross subsidy runs between them. The discipline parallels the one in RHEL on IBM Power licensing; the IBM mainframe and Power platforms each warrant their own register. The broader treatment of renewal cycle discipline sits in renewal negotiation; the sibling treatment of the certified SAP HANA line on Power sits in RHEL for SAP HANA licensing.

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.