OpenShift on bare metal versus virtualized, on the breakeven core count.
OpenShift on bare metal versus virtualized cost in 2026 reads through three quantities at the renewal table: the OpenShift line on the cluster worker cores, the underlying hypervisor licensing where the cluster sits inside a virtualization layer, and the density delta that the operational team can sustain when the host abstraction is removed. The bare metal posture removes the hypervisor line but exposes the OpenShift line to the full physical core count of the worker hardware; the virtualized posture preserves the hypervisor line and lets the OpenShift line read on a smaller virtualized worker core count at the cost of an additional layer. The breakeven turns on which line the buyer actually pays.
The two postures, and the line each one carries.
OpenShift Container Platform runs on bare metal hosts or on virtualized hosts that present virtual machines as worker nodes to the cluster. The two postures are operationally similar from the perspective of the workload and architecturally similar from the perspective of the Red Hat subscription line; both read on worker cores, both count in pair units, both follow the same conventions on physical cores versus logical CPUs1. The difference lies in the layers underneath the worker node and in the lines the buyer pays at those layers.
On bare metal, the OpenShift cluster runs directly on the physical host. The worker node is the host. The OpenShift line reads on the physical worker cores of every host in the cluster. There is no hypervisor licensing line because there is no hypervisor; the OpenShift Container Platform installer provisions the underlying RHEL CoreOS layer as part of the platform installation, and that layer is covered by the OpenShift subscription itself.
On virtualized hosts, the OpenShift cluster runs inside virtual machines that the underlying hypervisor presents. The worker node is the virtual machine. The OpenShift line reads on the virtual cores assigned to those virtual machines rather than on the full physical core count of the underlying host. The host itself carries a separate hypervisor licensing line on a per host basis: a VMware vSphere line on VMware hosts, a Microsoft Hyper V line on Windows Server hosts, a Red Hat OpenShift Virtualization or alternative open virtualization line on open hosts2.
The density delta, and where the savings sit.
The economic argument for OpenShift on bare metal turns on density and on the absence of the hypervisor line. Density rises because the OpenShift scheduler can pack pods directly against the physical hardware without the overhead a virtualization layer imposes. The operational team that runs OpenShift on bare metal commonly observes a fifteen to twenty five percent density improvement against the equivalent virtualized cluster, depending on the workload mix and the virtualization overhead at the host platform3.
The economic argument against OpenShift on bare metal turns on operational flexibility and the recoverable surface inside the virtualization layer. A virtualized cluster can be expanded by adding new virtual machines without provisioning new physical hardware. A virtualized cluster can share the host fleet with non OpenShift workloads such as Windows servers, legacy applications, or database tiers that do not run on Kubernetes. A bare metal cluster requires dedicated physical hardware for the OpenShift fleet, which is operationally cleaner but inventory wise less flexible.
The breakeven depends on the size of the hypervisor line that the bare metal posture would remove. On VMware vSphere with the post 2024 Broadcom pricing reading, the hypervisor line is materially larger than it was under the legacy VMware contract structure, and the bare metal posture removes a larger annual cost than it did three years earlier. On open hypervisor stacks with low licensing overhead, the bare metal posture removes a smaller annual cost, and the breakeven shifts toward virtualization because the density delta is no longer enough to overcome the loss of flexibility.
Three counting traps across the breakeven.
Three counting traps produce most of the variance observed across bare metal versus virtualized engagements in the trailing twelve months.
The first trap is the bare metal cluster scoped against the virtualized worker count from the prior platform. A buyer who ran an eighty virtual core OpenShift cluster on a forty physical core virtualization layer signs a bare metal renewal at eighty cores, then provisions the bare metal fleet at the eighty core physical specification because the cluster sizing tool returned that number. The bare metal posture then reads on the physical core count of the new hardware, which may be one hundred and twenty cores once the operational team selects standard data centre nodes. The mitigation is a physical hardware specification at signature that captures the actual core count of the planned bare metal hosts.
The second trap is the virtualized cluster that hosts OpenShift Virtualization workloads alongside the OpenShift platform. The cluster carries the OpenShift line on the virtual worker cores and the OpenShift Virtualization line on the virtual machines hosted by the cluster, and both lines accrue against the same physical hardware footprint. The buyer who treats the virtualized posture as cheaper because the per virtual core line is lower than the bare metal line discovers that the virtualization layer underneath has its own line and the OpenShift Virtualization workloads have a third line, and the combined arithmetic favours bare metal more often than the per virtual core reading suggests.
The third trap is the partial migration where some clusters run bare metal and others run virtualized without a clear contract record of which line accrues on which cluster. The audit reads against the contract record; where the record is silent, the audit reads the larger of the two readings. The decomposition at signature tends to surface an eight to fourteen percent saving against the unstructured posture, recurring annually across the term.
| Pattern | Frequency | Reading |
|---|---|---|
| Bare metal with physical specification at signature | 3 of 11 | Pays |
| Virtualized with hypervisor line decomposed | 3 of 11 | Pays |
| Bare metal sized against virtual worker count | 3 of 11 | Traps |
| OpenShift Virtualization line not surfaced | 1 of 11 | Traps |
| Partial migration without contract decomposition | 1 of 11 | Traps |
Reading the breakeven against the operational reality.
The bare metal versus virtualized decision reads against the cluster profile, the host platform underneath, and the operational flexibility the application portfolio requires. The cluster profile that runs predictable steady state workloads at high utilisation favours bare metal because the density delta sits at the high end and the operational flexibility cost is low. The cluster profile that hosts unpredictable workloads with bursty utilisation favours virtualization because the host fleet can flex more easily and the lower per virtual core reading offsets the hypervisor line.
The host platform underneath matters because the hypervisor line that the bare metal posture removes is platform specific. The buyer running VMware vSphere on post 2024 Broadcom pricing removes a larger line by going bare metal than the buyer running an open hypervisor stack. The buyer running Microsoft Hyper V or Nutanix AHV reads a different line and a different removal arithmetic. The breakeven decision should be cluster by cluster and host platform by host platform rather than a single posture across the entire OpenShift estate.
For the broader cross product reading, see the OpenShift practice hub, the GPU entitlement read for the parallel core counting mechanics on AI nodes, the ACM pricing read for governance across mixed bare metal and virtualized clusters, the edge deployment read for the parallel sizing question at the edge, and the RHEL on IBM Power read for the parallel bare metal counting conventions on Power hardware. For the engagement protocol, see renewal negotiation and contact.
Notes & references
- 1. Red Hat OpenShift subscription guide, accessed across 2025 and 2026. The platform line reads on worker cores in pair units on physical cores rather than on logical CPU count, with the same conventions on bare metal and virtualized clusters.
- 2. On virtualized clusters, the host fleet underneath carries a hypervisor line that is independent of the OpenShift subscription. The hypervisor line varies by host platform and by the licensing structure of the chosen virtualization stack.
- 3. Density delta in the trailing twelve months on bare metal versus virtualized clusters observed in the practice ranges from fifteen to twenty five percent, depending on workload mix and virtualization overhead at the host platform.
- 4. Practice observation across eleven bare metal versus virtualized engagements settled in the trailing twelve months. The most common exposure pattern is a bare metal cluster sized against the virtual worker count from the prior platform rather than against the physical specification of the new hardware.
- 5. Concession bands and trailing twelve month figures refer to the practice observation across signed contracts. The eighty two percent audit exposure reduction in marginalia is the trailing twelve month average across defenses settled.
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.