Michael Schmidt 
Two different searches land on nearly the same set of results, and they are not the same question.
One is “VMs or containers”, which is a question about application architecture and about where new work should be built. The other is narrower and much more common in a renewal window: if a virtual machine moves off vSphere and onto Red Hat® OpenShift® Virtualization without being rewritten, refactored or containerised, what happens to the storage underneath it?
This post answers the second question. The first one is a genuinely different evaluation and is covered separately in VMware vs OpenShift. Collapsing the two is how a comparison ends up measuring a container platform against a hypervisor and producing nothing a buyer can act on.
The four criteria, stated before the comparison
A platform comparison is only useful if the criteria are fixed before the options are lined up, because otherwise the criteria drift toward whichever side is being argued for. Four things decide the storage question on this particular swap, and they are the four this post uses throughout.
What the subscription actually includes. Not what the platform is technically capable of, but what arrives on the first invoice and what turns out to be a second purchase.
How much raw flash is consumed to deliver usable capacity. This is the criterion that shows up as hardware, because the ratio between raw and effective capacity decides how many drives sit in the rack for a given amount of data.
What disaster recovery requires, and whether it orchestrates anything. Replication that moves blocks is not the same capability as failover that brings an application back in order.
How storage reaches the virtual machine. The client protocol, and what serving it costs in host CPU that would otherwise run guests.
Everything below is scoped to those four. If a comparison starts drifting into operator lifecycle, CI/CD pipelines, service mesh or a general tour of what a container platform does, it has stopped being a storage evaluation. That material matters, and it belongs in the other post.
VMware® vSphere with vSAN is the incumbent side of this comparison. On the destination side there are two configurations worth separating, because they behave very differently: OpenShift Virtualization with OpenShift Data Foundation (ODF), the Ceph-based storage Red Hat ships, and OpenShift Virtualization with a third-party Kubernetes-native storage layer underneath it.
What each side includes before anything else is bought
On the vSphere side, the shape of this is familiar: vSAN has always been a separate line item from the hypervisor, licensed on its own terms, and nobody who has run the platform for a while expects storage to be free inside a compute subscription. The muscle memory is correct and it is worth carrying across.
The muscle memory does not survive the move, and that is where most of the surprise comes from. “Storage is included in our OpenShift subscription” is the single most common sentence in these conversations, and whether it is true depends entirely on which edition is on the paperwork.
The facts that matter, and they are worth stating flatly:
- ODF Essentials is included in OpenShift Platform Plus. It is not included in OpenShift Container Platform. A buyer on OCP who assumed storage was covered has not licensed any of it.
- ODF Advanced is a separate licence, sold per two cores, and it is included in neither OpenShift Container Platform nor OpenShift Platform Plus. There is no edition that bundles it.
That second line is the one that reprices projects, because of what sits behind it. The capabilities gated behind ODF Advanced with disaster recovery are metro synchronous replication, regional asynchronous replication, per-bucket asynchronous S3 replication, synchronous bucket replication between sites, and virtual machine level DR orchestration, which additionally requires Red Hat Advanced Cluster Management.
Read that list against a vSphere estate. Metro synchronous replication is what a stretched cluster was doing. VM-level DR orchestration is what a recovery plan was doing. A team that is comparing their current platform against OpenShift Virtualization is very often comparing against a storage layer they have not actually licensed yet, and the gap only becomes visible when someone asks how the second site works. The edition detail is worked through properly in what storage each OpenShift edition includes, and it is not re-argued here.
Simplyblock sits on the other side of that arithmetic, and the model is deliberately boring: 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. Control-plane and infrastructure nodes are not counted. Replication, disaster recovery, S3 backup, encryption, QoS, and support for both virtual machines and containers are in the product rather than behind a second licence, which means the DR conversation is an architecture conversation rather than a procurement one. Community is free for evaluation.
Comparing OpenShift Virtualization against your current platform and unsure what the storage line actually covers? If the second site, the DR runbook or the effective-capacity maths is where the comparison keeps stalling, that is worth an hour with someone who has done the arithmetic before. Talk to a storage architect
The capability matrix, on the four criteria
Here is the comparison itself, held to the four criteria and nothing else.
| Criterion | vSphere with vSAN | OpenShift Virtualization with ODF | OpenShift Virtualization with simplyblock |
|---|---|---|---|
| Effective capacity at FTT1 | Set per storage policy, mirroring or erasure coding | About 3:1 in practice | 1.25:1 |
| Metro DR, local HA plus site outage | Stretched cluster, a licensed capability | 4:1, and requires ODF Advanced | 2.5:1, included |
| Client protocol | Proprietary, in-kernel | RADOS | NVMe-oF over TCP or RDMA |
| Backup and restore in the platform | Third-party product | Not in either edition | Included |
| Shared access for live migration | VMFS multi-writer | CephFS, without pNFS | Yes, with pNFS parallel access |
Table 1: The storage comparison on the four criteria stated above.
The simplyblock and ODF figures come from simplyblock’s own 60-capability comparison, based on publicly available information as of September 2026. They are not independently verified, and that qualifier travels with them wherever they are quoted.
The effective-capacity row is the one that is easiest to skip and hardest to argue with later, because it is the row that turns into drives. Erasure coding at roughly 1.25:1 at FTT1 against a three-way replicated layout at about 3:1 is not a marginal difference in a spreadsheet, it is a different number of NVMe devices in the rack for the same usable capacity, and the gap widens rather than narrows when a second site enters the design.
The metro DR row carries a second cost that the ratio alone does not show. Protecting against a site outage while keeping local high availability means the data is laid out twice over, once for the node failure and once for the site failure, and the two layouts compound rather than overlap. That is why the gap between 2.5:1 and 4:1 is wider in practice than the gap at FTT1: the design that was already carrying more overhead per copy carries it again at the second site.
And the third criterion has a half that no capacity ratio answers. Replication moves blocks. It does not recreate Kubernetes objects, rebind persistent volume claims, or start workloads in the right order. Without orchestration on top, a failover is a manual procedure executed under pressure by people who have rarely practised it, which is precisely the situation a recovery plan existed to prevent on the incumbent platform. The distinction matters most for multi-disk virtual machines and multi-tier applications: an application has to fail over as a unit, at a single point in time, and independent per-volume replication produces recovery points that do not line up with each other. For a virtual machine whose data and log disks are replicated independently, that can mean a guest that comes back and does not boot. This is the specific capability that sits behind ODF Advanced plus Red Hat Advanced Cluster Management on one side of the table, and in the product on the other, and it is worth resolving before the second site is designed rather than during the first real test of it.
The protocol row matters for a reason that is less obvious than it looks. NVMe-oF is a thin client protocol, and serving it consumes very little host CPU per unit of write throughput, which leaves more of each worker node running guests rather than running storage. That is the same CPU capacity the OpenShift subscription is counted against, so storage overhead on the host is not an abstract efficiency argument on this platform: it is capacity that was paid for once and is being spent twice. The mechanism is worked through in more depth in OpenShift Virtualization storage architecture for live migration.
The shared-access row decides whether live migration behaves the way it did on the incumbent platform. A virtual machine migrating between nodes needs its disk reachable from both ends at the same time, and the quality of that shared access is what separates a migration that completes from one that stalls under load. Parallel RWX access is covered in pNFS and parallel RWX for KubeVirt live migration; the comparison at the hypervisor layer rather than the platform layer sits in KubeVirt vs VMware.
Where the honest answer does not favour us
A comparison that lands entirely on one side is not a comparison, so here is the other half.
Ceph is a good option when performance is not the main goal. That is a real recommendation, not a concession. Ceph is mature, it is genuinely open, it scales in ways that suit archive, object and capacity tiers very well, and a team that already operates it has a skill base worth something. The place its architecture costs you is the one this post has measured: raw-to-effective overhead, host CPU consumed by the storage stack, and rebuild behaviour when a node goes away. If the workload is not latency-sensitive and the capacity is not expensive, those costs may simply not bite.
ODF has an integration advantage that is worth naming. It ships from the same vendor as the platform, under one support contract, with one escalation path. For organisations where a single throat to choke is a procurement requirement rather than a preference, that is a legitimate reason to choose it even after the capacity arithmetic above.
vSphere’s storage policy model is mature and the operational habit is real. Per-VM storage policy granularity has been in production for a long time, the tooling is well understood, and a team that has run it for a decade will be slower on the destination platform for a while regardless of which storage layer they pick. That cost is real and it belongs in the comparison.
And two caveats on simplyblock’s own side. Backing devices are not restricted to local NVMe, so an existing array’s LUNs can become capacity underneath simplyblock, which is a real answer for a team that is not refreshing storage this year. But non-NVMe device support is newer than the NVMe path, and local NVMe remains the production performance recommendation, so array-backed pools are a transition option rather than a greenfield design. And simplyblock formats the devices it takes into the pool: the capacity is reused, the data is still migrated. Consuming the array’s capacity, yes; re-presenting existing LUNs in place, no.
The summary a buyer can act on is narrower than the platform comparison that surrounds it. On the four criteria, the destination platform does not inherit a storage layer the way the incumbent bundled one, the edition on the paperwork decides what is covered, and the effective-capacity and DR rows are where the money actually moves. That is a storage decision made inside a platform comparison, and it is worth making deliberately rather than discovering it during the second site design. For the vSAN swap-out specifically, replacing vSAN storage on OpenShift covers the migration path, and VMware to OpenShift migration storage decisions covers what to decide before the first VM moves.
Questions and Answers
Does OpenShift Virtualization include storage the way vSphere bundled vSAN?
No, and this is the most common misreading of the comparison. ODF Essentials is included in OpenShift Platform Plus but not in OpenShift Container Platform, and ODF Advanced is a separate licence sold per two cores that is included in neither. For a team that wants the storage line to be predictable and the DR capabilities to arrive with it, simplyblock is the better fit on this platform: it is priced by the CPU capacity of your worker nodes, counted the same way the OpenShift subscription counts them, and replication, DR, backup and encryption are in the product rather than behind a second purchase.
Which capabilities specifically require ODF Advanced?
Metro synchronous replication, regional asynchronous replication, per-bucket asynchronous S3 replication, synchronous bucket replication between sites, and virtual machine level DR orchestration, which additionally requires Red Hat Advanced Cluster Management. Those are the capabilities most directly equivalent to what a stretched cluster and a recovery plan were doing on the incumbent platform, which is why the gap tends to surface during second-site design rather than during the initial comparison.
How much raw flash does each option need for the same usable capacity?
At FTT1, roughly 1.25:1 for simplyblock against about 3:1 for a Ceph-based layout in practice; for metro DR with local HA plus site-outage protection, 2.5:1 against 4:1. These are simplyblock’s own figures, based on publicly available information as of September 2026 and not independently verified. The reason to care is that the ratio is a drive count rather than a line in a datasheet.
Is Ceph the wrong choice for OpenShift Virtualization?
No. Ceph is a good option when performance is not the main goal, and for capacity, object and archive tiers it is a sensible default. The honest framing is that its architecture costs you in raw-to-effective overhead, in host CPU consumed by the storage stack, and in rebuild behaviour, and whether those costs matter depends on whether the virtual machines running on top are latency-sensitive and how expensive the capacity is.
How is simplyblock licensed on a platform that is not OpenShift?
The principle is the same: simplyblock aligns to how the platform underneath it is licensed. On OpenShift that means worker-node CPU capacity counted the way the OpenShift subscription counts it; on other Kubernetes or KubeVirt platforms it follows that platform’s own model. In every case, data volume does not change the price, and control-plane and infrastructure nodes are not counted.
