OpenShift cores, counted on virtualization.
OpenShift core counting in virtualized environments is the most common 2026 audit dispute on the container platform. The counting mechanic the audit team applies by default rarely matches the mechanic the customer's contract actually establishes, and the gap is largest in VMware and KVM estates where the cluster sits on hypervisors that the audit team can read either way. The defense begins by reading the contract's counting mechanic into the response language before any cluster manifest is shared. This note treats the mechanic, the divergence, and the response position.
What a core actually is.
An OpenShift core, in the contractual sense, is a counting unit on the worker nodes of an OpenShift cluster, and the question of what counts as a worker node and which cores on that node count toward the subscription is the question OpenShift core counting in virtualized environments turns on. The contractual definition is rarely the engineering definition. The engineering definition is a logical processor that the operating system can schedule work onto; the contractual definition is a physical core on a worker node assigned to running customer workloads. The two definitions diverge under hyperthreading and under virtualization, and they diverge again when control plane nodes, infra nodes, and bootstrap nodes are introduced to the cluster topology.1
Across the OpenShift audit defenses settled in the trailing twelve months, the core definition was the dominant counting dispute in seven of nine matters. In every case the audit team applied the broader of the available definitions. In every case the response was able to assert a narrower definition supported by the contract. The work was not technical demonstration of the cluster topology; it was contractual demonstration of which cores count.
The companion notes on hyperthreading and control plane treatment and core counting in mixed environments treat parts of the mechanic in detail. The present note focuses on virtualization specifically.
The hypervisor read and the worker node read.
The hypervisor read counts cores at the level of the physical host on which the OpenShift virtual machines run. The worker node read counts cores at the level of the OpenShift worker node itself, which is a virtual machine on the hypervisor. The two reads produce different numbers for the same cluster and the audit team's default is to choose the larger of the two.
The hypervisor read is the broader of the two and the harder to defend on contract. It treats all physical cores on the hypervisor as in scope for OpenShift, on the theory that any guest could in principle be an OpenShift worker. The reading is rarely supported by the contract; the contract typically counts entitlement against worker nodes, not against hypervisor hosts. The response position is therefore the worker node read, and the response language asserts it before any cluster topology is shared.2
The worker node read is contractually supported in nearly every OpenShift agreement the practice has reviewed in 2026. The cores on the worker node are the cores assigned to the virtual machine that runs as a worker. Where the OpenShift virtual machine is sized with eight virtual CPUs on a hypervisor with sixty four physical cores, the worker node read counts eight; the hypervisor read counts sixty four. The audit team's default on a six worker cluster of this shape would count three hundred and eighty four cores; the contractual reading counts forty eight.
The note on OpenShift practice sets the product context. The note on OpenShift Virtualization licensing treats the inverse question, where OpenShift itself is the hypervisor for non OpenShift virtual machines.
Hyperthreading and the contract's silence.
Hyperthreading produces a second counting dispute that compounds the hypervisor versus worker read. On Intel hyperthreaded processors, each physical core presents two logical processors to the operating system. The audit team's default reading counts logical processors. The contract typically counts physical cores. The two readings produce a factor of two divergence on the same cluster, on top of the hypervisor read.
| Reading combination | Sample cluster cores | Multiple of contract |
|---|---|---|
| Worker node, physical cores (contract) | 48 | 1.0× |
| Worker node, logical processors | 96 | 2.0× |
| Hypervisor, physical cores | 384 | 8.0× |
| Hypervisor, logical processors | 768 | 16.0× |
The figure illustrates why the OpenShift core counting question dominates 2026 audit defenses. A finding produced against the hypervisor with logical processors reading is sixteen times the finding produced against the contractual reading on the same cluster. The audit team rarely sustains the worst case at settlement; the response work compresses the multiple as the matter progresses. The starting position the response asserts in the first letter is therefore the position that anchors the eventual settlement.
Control plane and infra node treatment.
The cluster topology has three classes of node beyond the worker. Control plane nodes run the cluster's own control software. Infra nodes run platform services that support the cluster but do not run customer workloads. Bootstrap nodes are transient artefacts of cluster installation. The contract typically exempts all three from the worker count. The audit team's default reading rarely honours the exemption.3
The control plane exemption is the largest of the three and the most defensible. OpenShift control plane nodes do not run customer workloads under any supported configuration; the contract reflects this by excluding them from the worker count. The response position is that control plane nodes are out of scope and the cluster topology evidence demonstrates which nodes hold the control plane role. The audit team typically accepts the position once the topology is documented in the response.
The infra node exemption is operationally important and contractually more subtle. Infra nodes run logging, monitoring, registry, and ingress services. The contract typically exempts dedicated infra nodes from the worker count. Where the customer has labelled nodes as infra in cluster configuration and assigned only platform services to them, the exemption applies. Where customer workloads have been allowed to schedule on infra nodes through over permissive scheduling, the audit team reads the nodes as worker. The response position is the documented infra role; the supporting note on self managed against dedicated and ROSA treats the infra question across the OpenShift variants.
Where the counting meets the defense.
The OpenShift core counting defense is operationally sequential. The response asserts the worker node read against the hypervisor read first, because the hypervisor read is the broader of the two. The response asserts physical cores against logical processors second, because hyperthreading is the multiplier that runs on top of whichever node level read prevails. The response asserts the control plane and infra exemptions third, because these are local adjustments inside the worker count once it has been bounded. The order matters; arguing hyperthreading before worker node read is arguing about a multiplier without bounding the base.
The cluster topology evidence is produced after the response language has been filed and the audit team has acknowledged the counting framework in writing. The evidence produced in the contractual framework is then read against the cited mechanic. The cluster manifest returned in the audit team's default template inherits the audit team's mechanic; the cluster manifest returned in the contract's mechanic inherits the contract's.
The note on responding to the compliance letter treats the broader response posture; the present note treats the OpenShift counting paragraph specifically. The companion note on RHEL socket pair against virtual datacenter treats the parallel mechanic on the operating system side.5
If the audit notice references OpenShift directly and asks for cluster level evidence, the first useful hour is a call with the practice. The note on Red Hat audit defense as a service sets out the engagement protocol; the present note treats the counting work inside that protocol.
Notes & references
- 1. Core definition. Red Hat's OpenShift subscription documentation defines the unit of consumption at the worker node level, in physical cores. Contractual instruments typically incorporate this definition by reference; audit defenses turn on the precise reference language.
- 2. Hypervisor reading. The audit team's hypervisor reading treats all physical cores on a host as in scope where any OpenShift workload runs on the host. The practice has not seen the reading sustained at settlement in any of the nine recent OpenShift defenses.
- 3. Control plane exemption. The control plane exemption is present in nearly every OpenShift agreement the practice has reviewed. Where the customer's agreement does not include the exemption explicitly, Red Hat's published subscription documentation establishes the exemption by reference.
- 4. Worst case multiple. The 16x multiple in the figure reflects the worst case reading combination on a hyperthreaded virtualized cluster. The practice has not seen a settlement close at 16x; the worst observed settlement closed at approximately 4x the contractual reading, on a customer who shared cluster manifests before the response was filed.
- 5. Order of assertions. The sequence worker read, then hyperthreading, then exemptions is operational. Reversing it produces a defense that argues the components in isolation; the audit team is structurally better positioned to push back on isolated components than on the framework.
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.