Rob Pankow 
Teams landing virtual machines on Red Hat® OpenShift® Virtualization after leaving vSphere run into a storage decision vSAN never made them think about twice: which storage platform actually runs underneath the KubeVirt control plane. The default instinct is to look for the closest thing to vSAN’s operating model, a commercial Kubernetes-native hyperconverged infrastructure (HCI) platform that bundles storage, replication, and a management plane into one product. That instinct is reasonable. It is also worth slowing down on, because the category has real structural tradeoffs that a demo rarely surfaces: per-core or per-node licensing that scales independently of how much storage you actually use, and a proprietary storage control plane that becomes its own migration project the next time you want to leave.
This isn’t an argument against commercial Kubernetes-native HCI platforms as a category. Several are mature, well-supported, and a legitimate fit for teams that want a single vendor to own the whole storage stack. It’s a checklist for what to verify before signing, because the decision looks a lot like a smaller version of the VMware exit itself if you get it wrong.
Why OpenShift Virtualization Storage Decisions Feel Familiar, and Different, From vSphere
vSAN made storage a property of the hypervisor: buy the license, storage policies attach to VMs, and the whole stack is one vendor’s problem to support. OpenShift Virtualization runs VMs as KubeVirt workloads on top of standard Kubernetes primitives, which means storage is a separate decision made through the Container Storage Interface (CSI), not something bundled into the hypervisor license. That separation is the whole point of moving to a Kubernetes-native platform: storage, compute, and the virtualization layer can each be sourced, scaled, and replaced independently.
A commercial Kubernetes-native HCI platform partially undoes that separation. It reintroduces a single-vendor bundle, this time wrapped around a CSI driver instead of a hypervisor, with its own storage cluster, its own management UI, and its own replication engine running on the same nodes as your VMs. For some platform teams that’s exactly the tradeoff they want: less to integrate, one throat to choke. For others it recreates the lock-in they left vSphere to escape, just with a different vendor’s name on it. The right call depends on questions the pitch deck won’t answer for you.
What a Commercial Kubernetes-Native HCI Platform Actually Costs
The licensing model is the first thing to pressure-test, because “Kubernetes-native” and “open source” get used loosely in this category, and the commercial tier is where the real cost sits. Most commercial HCI storage platforms for Kubernetes license per CPU core or per node in the cluster, independent of how much storage capacity is actually provisioned. That model rewards vendors when you add compute, whether or not your storage footprint grows, and it means a GPU-dense or compute-heavy OpenShift Virtualization cluster pays a storage premium that has nothing to do with storage.
Table 1: Licensing and lock-in comparison for OpenShift Virtualization storage platforms
| Dimension | Typical commercial Kubernetes-native HCI platform | simplyblock |
|---|---|---|
| Pricing basis | Per CPU core or per node, scales with compute added | Per usable storage TB/yr, scales with capacity provisioned |
| Hypervisor / platform support | Locked to the vendor’s own Kubernetes-native stack | Any hypervisor: vSphere, Hyper-V, bare-metal Kubernetes, KubeVirt, OpenShift |
| Deployment model | Hyperconverged only, storage and compute co-located | Hyperconverged or disaggregated, same control plane |
| Storage control plane | Proprietary, vendor-specific management layer | CSI-native, standard Kubernetes primitives |
| Compute/storage scaling | Coupled, adding compute nodes adds storage capacity whether needed or not | Independent, scale each tier to what the workload actually needs |
Two consequences follow directly from a per-core model. First, cost is unpredictable at planning time, because it tracks a compute decision (how many cores, how many nodes) rather than a storage decision (how much data, at what durability). Second, it penalizes hardware density: consolidating onto fewer, denser nodes to save on power and rack space raises the per-core storage bill even when the storage footprint stays flat. A capacity-based model, priced per usable TB/yr, ties the storage bill to the thing storage actually does, hold data, and rewards density instead of taxing it.
A per-core storage bill grows every time you add compute, whether storage needs it or not. Talk to a storage architect about sizing OpenShift Virtualization storage on usable capacity, not CPU count. Talk to a storage architect
The Control-Plane Question: Proprietary HCI Stack vs. CSI-Native Storage
The second thing to verify is what happens to your workloads if you ever want to leave the platform. A commercial Kubernetes-native HCI platform typically owns its own storage control plane end to end: its own CSI driver, its own replication and rebuild logic, its own snapshot format, often its own management UI separate from the OpenShift console. That’s the same value proposition vSAN offered, deep integration in exchange for the vendor owning the full stack, and it comes with the same tradeoff: your PersistentVolumeClaims, snapshot policies, and StorageClass definitions are only portable in the ways that vendor’s control plane allows.
A CSI-native storage layer keeps that same deep integration, QoS policies, snapshot scheduling, per-volume replication settings, expressed through standard Kubernetes objects: StorageClass, VolumeSnapshotClass, PersistentVolumeClaim. Nothing about that requires giving up the operational depth a commercial HCI platform provides. What it avoids is the second migration project: if the storage layer is addressed entirely through CSI primitives, moving the same manifests to a different OpenShift cluster, a different Kubernetes distribution, or even a different storage vendor is a StorageClass change, not a data-format conversion.
Fabric and Deployment Flexibility: Hyperconverged, Disaggregated, and the NVMe Options
Most commercial Kubernetes-native HCI platforms are hyperconverged only by design, storage and compute co-located on the same nodes, because that’s what the “HCI” label promises. That’s a legitimate model, and it’s the right fit when node count is small and operational simplicity outweighs independent scaling. It stops being the right fit the moment GPU or compute-dense nodes need to scale faster than storage capacity does, or vice versa, because a hyperconverged-only platform forces both to grow together.
A storage layer that supports both hyperconverged and disaggregated deployment from the same control plane removes that constraint. Storage and compute can live on the same nodes when that’s simpler to operate, or on dedicated storage nodes connected over NVMe/TCP or NVMe/RoCE when a workload needs to scale one tier independently of the other. The fabric choice matters too: NVMe/TCP runs over standard Ethernet with no specialized network hardware, while NVMe/RoCE trades that simplicity for lower latency on networks that already have RDMA-capable NICs and lossless fabric configured. A platform locked to one deployment model, or one fabric, answers today’s cluster shape. A platform that supports both answers the shape the cluster will be in eighteen months.
A Practical Checklist Before Committing to Any Kubernetes-Native HCI Storage Platform
Before signing a contract with any Kubernetes-native HCI vendor for OpenShift Virtualization, four questions are worth getting in writing rather than inferring from the sales deck:
- Does the price scale with storage capacity or with compute? A per-core or per-node model means your storage bill moves every time the compute footprint changes, regardless of actual storage usage.
- Can workloads run on any hypervisor or platform, or only this vendor’s stack? Locked-in platform support recreates the single-vendor dependency a VMware exit was meant to end.
- Is the storage control plane addressed through standard CSI objects, or a proprietary management layer? The former keeps
StorageClassandPersistentVolumeClaimdefinitions portable; the latter ties them to that vendor’s tooling. - Can compute and storage scale independently, and does the platform support both hyperconverged and disaggregated deployment? A hyperconverged-only design works until one tier needs to grow faster than the other.
None of these questions disqualify commercial Kubernetes-native HCI platforms outright. They’re the same questions worth asking of any vendor claiming to solve OpenShift Virtualization storage, simplyblock included, and the answers are what separates a genuine fit from a second lock-in disguised as an exit from the first one.
Questions and Answers
What storage does OpenShift Virtualization use for VM disks? OpenShift Virtualization runs VMs as KubeVirt workloads, and VM disks are backed by standard Kubernetes PersistentVolumeClaims provisioned through a CSI driver, the same storage interface used for any other Kubernetes workload. The storage platform behind that CSI driver, whether a commercial Kubernetes-native HCI product or another CSI-compliant backend, determines performance, replication, and snapshot behavior.
Is a commercial Kubernetes-native HCI platform a bad choice for OpenShift Virtualization? Not inherently. It’s a legitimate choice for teams that want a single vendor to own the full storage stack and value that operational simplicity over independent compute/storage scaling. The risk is committing without checking whether the licensing model, hypervisor support, and control-plane portability match how the cluster will actually grow.
What’s the difference between hyperconverged and disaggregated storage for OpenShift Virtualization? Hyperconverged storage runs on the same nodes as compute, which is operationally simple but couples storage and compute scaling together. Disaggregated storage runs on dedicated nodes connected over a fabric like NVMe/TCP or NVMe/RoCE, which adds a network hop but lets each tier scale independently. Simplyblock supports both from one control plane, so the choice is a deployment decision, not a platform decision.
How is simplyblock priced compared to a commercial Kubernetes-native HCI platform? Simplyblock licenses per usable storage TB per year, with no per-core or per-node fee. Cost scales with the storage capacity actually provisioned, not with how many CPU cores or nodes the cluster runs, so consolidating onto denser hardware lowers cost instead of raising it the way a per-core model would.
Does simplyblock lock OpenShift Virtualization workloads into a proprietary control plane? No. Simplyblock is addressed entirely through standard Kubernetes CSI primitives, StorageClass, VolumeSnapshotClass, and PersistentVolumeClaim, so QoS policies, snapshot schedules, and replication settings are portable Kubernetes objects rather than entries in a vendor-specific management UI.
