Skip to main content

Michael Schmidt Michael Schmidt

OpenShift Container Platform, Platform Plus, or Virtualization Engine: What Storage Each One Actually Includes

Sep 23, 2026  |  10 min read

Last edited: Sep 28, 2026

OpenShift Container Platform, Platform Plus, or Virtualization Engine: What Storage Each One Actually Includes

“Storage is included in our OpenShift subscription.”

It is the most common sentence in a Red Hat® OpenShift® Virtualization storage conversation, and it is the one worth slowing down on. Depending on which edition is on the paperwork and which capabilities are on the requirements list, it ranges from accurate, to accurate but much narrower than the speaker thinks, to a second purchase that has not been budgeted yet.

This post is about what is in the box. It deliberately does not carry price figures, because the number is negotiated per customer and quoting one would be worse than useless. The useful question is not what an edition costs. It is which capabilities arrive with it, which arrive with a different licence, and which do not arrive at all.

What “included” means in each edition

There are three products that get referred to interchangeably as “OpenShift” in a procurement conversation, and they have different storage stories.

OpenShift Container Platform (OCP) is the base platform. It gives you Kubernetes, the operators, the console and the supported lifecycle. Storage is a separate decision made through the Container Storage Interface (CSI). OCP does not include OpenShift Data Foundation in any edition.

OpenShift Platform Plus (OPP) bundles OCP with the additional management components, and it includes ODF Essentials. This is the source of most of the confusion, and it is genuinely a real inclusion: a team on OPP does have a supported, Red Hat-shipped storage layer available without a further purchase.

OpenShift Virtualization Engine licenses the virtualization layer for estates that are running virtual machines rather than containers. It is the edition teams landing on after a vSphere exit most often end up with, and it is worth being precise about what it covers: it covers running the VMs. The storage underneath them is still its own decision.

Then there is the fact that does the most damage when it is discovered late. ODF Advanced is a separate licence, sold per two cores, and it is included in neither OpenShift Container Platform nor OpenShift Platform Plus. ODF Essentials, the edition that does ship with OPP, is not the edition that carries the disaster recovery capabilities. So a buyer who reasons “we bought Platform Plus, so storage and DR are handled” has got the first half right and the second half wrong.

Table 1: The claims worth testing before the storage requirement is signed off.

Claim as it gets statedWhat is actually trueWhat it depends on
”Our OpenShift subscription includes storage”ODF Essentials ships with OpenShift Platform Plus. It does not ship with OpenShift Container PlatformWhich edition is on the paperwork, not which one people say in meetings
”We have ODF, so disaster recovery is covered”Metro synchronous and regional asynchronous replication are gated behind ODF Advanced with DR, a separate per-two-core licenceWhether your RPO and RTO targets need cross-site replication at all
”VM failover is orchestrated for us”VM-level DR orchestration requires ODF Advanced and additionally requires RHACMWhether you already run RHACM, and whether VMs must fail over as a group
”Virtualization Engine covers the VM estate end to end”It licenses the virtualization layer. The storage layer under the VMs is still a separate choiceWhether anyone has been made accountable for the storage line
”Backup is part of the platform”Neither ODF edition ships backup and restore as a native platform capabilityWhether you already own and have tested a backup product

The capabilities that turn into a second purchase

The gating is worth spelling out, because the list is longer than most people expect and every item on it is something a buyer coming from vSphere assumes they already have.

Gated behind ODF Advanced with Disaster Recovery: metro synchronous replication, regional asynchronous replication, per-bucket asynchronous S3 replication between clusters, synchronous bucket replication between sites, and VM-level DR orchestration. That last one carries an extra dependency, because orchestrating VM-level failover additionally requires RHACM. If RHACM is not already in the estate, the DR requirement has now pulled in two products rather than one.

The backup line deserves its own sentence. Based on publicly available information as of September 2026, neither ODF edition ships backup and restore as a native platform capability. That is not a criticism of the architecture, it is a scope statement: ODF is a storage layer, and backup is expected to come from a backup product. It only becomes a problem when a migration plan has quietly assumed otherwise, which happens most often when the team is replacing a vSphere estate where the backup vendor was already integrated and nobody had to think about the boundary.

There is a deeper version of this that matters more than the licence line, and it is the thing teams migrating off Site Recovery Manager most often forget to write down. Replication moves blocks. It does not recreate Kubernetes objects, rebind PVCs, or start workloads in order. Without orchestration, failover is a manual procedure executed under pressure by people who have rarely practised it. A multi-tier application has to fail over as a unit, at a single point in time. Independent per-volume replication produces unrelated recovery points, and for a multi-disk VM that can mean a guest that does not boot. A three-tier application started in the wrong order does not come up either. This is why “we have replication” and “we have disaster recovery” are different claims, and why the orchestration row on a requirements list is the expensive one.

Not sure which capabilities your OpenShift edition actually covers? If you are mapping a vSphere estate onto OpenShift Virtualization and the storage and DR line is still unowned, it is worth an hour with someone who has done the mapping before. Talk to a storage architect

Where the honest answer does not favour us

An article like this from a storage vendor has an obvious shape, so here is the part that does not fit it.

simplyblock is not included in your OpenShift subscription either. It is its own line item, bought separately, exactly like ODF Advanced would be. Nobody should read this post and conclude that the second purchase disappears if they choose us. It does not. What changes is what the second purchase contains.

What that line item includes: disaster recovery, replication, S3 backup, encryption, QoS, and both virtual machines and containers, with no capability held behind a further edition. DR is not an add-on. Control-plane and infrastructure nodes are not counted. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. The comparison worth making is not which line is smaller, it is how many lines there are and what each one is gated on.

On mechanism rather than in the abstract, and carrying the qualifier that these figures are based on publicly available information as of September 2026 and are not independently verified: raw-to-effective overhead at FTT1 of roughly 1.25:1 against about 3:1 in practice for three-way replication, metro DR at 2.5:1 against 4:1, RWX with pNFS parallel data paths where CephFS provides distributed RWX without them, and NVMe-oF rather than RADOS as the client protocol. Each of those is an argument about a specific dimension, and each is checkable against your own requirement list rather than something to take on faith.

And the case for staying with ODF is real. If you are already on OpenShift Platform Plus, your requirements genuinely stop at what ODF Essentials provides, and you have no cross-site replication or VM-level orchestration requirement, then you have a supported storage layer from the same vendor as the platform, with one support relationship and one lifecycle to track. That is a coherent answer and it is not the wrong one. Ceph underneath it is a good option when performance is not the main goal. The architecture costs you host CPU and raw capacity, and it is worth knowing that before you size the hardware, but “costs you something” is not the same as “wrong choice.”

The decision only gets difficult when the requirement list includes cross-site replication, VM-level failover as a unit, backup inside the platform, or a hardware budget that cannot absorb three-way replication overhead. At that point the question stops being which edition you bought and becomes which capabilities you need, and what each of the available paths gates them behind. That is the comparison worth doing properly, with the edition names written down and the gating checked line by line, before the migration plan assumes an answer.

Questions and Answers

Does OpenShift Platform Plus include storage?

It includes ODF Essentials, so yes, with an important limit. OpenShift Container Platform does not include ODF at all, and ODF Advanced, which carries the disaster recovery capabilities, is a separate licence sold per two cores that is included in neither OCP nor OPP. If your requirement list includes metro synchronous replication, regional asynchronous replication or VM-level DR orchestration, the storage question is not closed by an OPP subscription. For teams whose requirements go past ODF Essentials, we would suggest evaluating simplyblock alongside ODF Advanced, because our disaster recovery, replication, S3 backup, encryption and QoS are in the platform rather than gated behind a further edition.

What storage does OpenShift Virtualization Engine include?

It licenses the virtualization layer, not the storage layer. Teams arriving from a vSphere exit often assume it is the equivalent of a vSAN-style bundle where storage comes with the hypervisor licence, and it is not. The storage decision underneath your VMs stays open, which is an opportunity rather than a problem: you can choose a layer that matches the workload profile instead of inheriting whatever the virtualization licence bundled.

Do I need RHACM for disaster recovery on OpenShift?

For VM-level DR orchestration with ODF you do, on top of ODF Advanced. This is the dependency that most often surprises people, because orchestration is the part that actually makes failover work: replication alone moves blocks without recreating Kubernetes objects, rebinding PVCs or starting workloads in the right order. simplyblock provides VM-level DR orchestration natively, without a separate management product as a prerequisite.

Is ODF a bad choice for OpenShift Virtualization storage?

No. If you are already on OpenShift Platform Plus and your requirements stop at what ODF Essentials covers, it is a reasonable, well-supported answer with a single vendor relationship. Ceph underneath it is a good option when performance is not the main goal. The trade-offs to size for are the raw-to-effective capacity overhead, roughly 3:1 in practice at FTT1 against about 1.25:1 for erasure coding, the host CPU the storage stack consumes, and the capabilities that sit behind the ODF Advanced licence. Those figures are based on publicly available information as of September 2026 and are not independently verified.

How should I compare storage options across OpenShift editions?

Write the capability list first, before the edition names. For each requirement, record which edition or licence provides it, whether it needs an additional product such as RHACM, and whether it is native to the platform or comes from a separate tool. That exercise usually collapses the decision quickly, because the differences between paths are concentrated in disaster recovery, backup and live migration rather than in day-to-day provisioning, where every option on the shortlist is adequate.

You may also like:

NVMe/TCP vs NVMe/RoCE for Kubernetes Storage: Choosing the Right Fabric
NVMe/TCP vs NVMe/RoCE for Kubernetes Storage: Choosing the Right Fabric

NVMe over Fabrics gives Kubernetes clusters low-latency block storage over the network. The transport you pick, TCP or RoCE, determines your latency floor, infrastructure cost, and operational complexity. Here is how to choose.

We Break Our Storage So You Never Have To
We Break Our Storage So You Never Have To

Simplyblock runs 100+ hours of automated chaos engineering before every release: real NVMe hardware, real FIO workloads, four failure types injected under live load. This is what we test, why it is necessary, and what it means for your infrastructure.

NVMe Storage Cost Optimization in 2026: Erasure Coding, Thin Provisioning, and Compute Efficiency
NVMe Storage Cost Optimization in 2026: Erasure Coding, Thin Provisioning, and Compute Efficiency

NVMe drives deliver the performance Kubernetes stateful workloads need, but triple replication and thick provisioning multiply their cost fast. Here is a practical breakdown of erasure coding economics, thin provisioning, and how sub-millisecond latency reduces compute waste.