OpenShift Bare Metal vs Virtual Node Counting
Where your OpenShift worker nodes sit, on bare metal or inside virtual machines, changes how IBM counts the cores your Cloud Pak workloads consume. The same cluster can carry very different exposure depending on that one architectural choice and how it is reported. The substrate decides the math.
Why the substrate matters
Cloud Pak software is metered in Virtual Processor Cores, and the IBM License Service counts the virtual cores made available to the licensed containers. On bare metal worker nodes, a virtual core maps directly to a physical core, so the count tracks the hardware running the workload. On virtualized worker nodes, where OpenShift runs inside virtual machines, the count follows the virtual machine sizing, and sub-capacity terms can hold the number to the cores actually assigned, provided the reporting conditions are met. The architecture you chose for the cluster is therefore the first input to the bill.
Where node counting goes wrong
Two failure modes dominate. First, a virtualized cluster that should hold a sub-capacity position loses it because the License Service is not capturing the nodes continuously, so IBM reverts to counting the full underlying capacity. Second, a bare metal cluster is sized for peak and runs far below it, yet every core in the node is countable because there is no virtualization layer to scope down to. Either way, the gap between what the workload uses and what is chargeable is where findings live. The container rule makes this sharper: a compliance failure can pull all cores in the cluster into the count, not just the nodes running the licensed software.
- Bare metal counts physical cores: the virtual core maps to the physical core, so node sizing is the exposure
- Virtual nodes can scope down: sub-capacity can hold the count to assigned virtual cores when reporting is continuous
- The License Service is mandatory: without continuous capture, IBM counts the full capacity available to the cluster
- Cluster wide penalty: a container shortfall can charge all cores in the cluster, not only the licensed nodes
How buyers defend the node count
We map the cluster topology to the metric: which worker nodes are bare metal, which are virtualized, and how each maps to chargeable cores. We confirm the License Service is capturing the right nodes continuously, and we reconcile the reported VPC consumption against the entitlement. Where a virtualized cluster held a valid sub-capacity position, we defend it with the reporting evidence rather than let IBM sweep to full capacity. Where bare metal node sizing created idle but countable cores, we frame the rightsizing path so the forward count matches the real workload.
An auditor reading your OpenShift estate will ask whether each node is bare metal or virtual, and whether the License Service has been capturing the cores continuously. A virtualized cluster with clean reporting can hold a sub-capacity count; the same cluster without it, or a container shortfall anywhere in it, defaults to the full cluster. Document the topology and the reporting before the audit, so the node count is set by your evidence and not by the worst case IBM is entitled to assume.