Chris Engelbert 
Every VMware® exit plan currently in circulation shares an assumption so basic that nobody writes it down: that the destination is another hypervisor.
Sometimes it is a like-for-like one. Sometimes it is KubeVirt or Red Hat® OpenShift® Virtualization, where the virtual machines survive but the control plane underneath them becomes Kubernetes. Either way the mental model carries over. There are hosts, there is a scheduler that places virtual machines on them, there is shared storage the hosts can all reach, and the migration is a translation exercise between two versions of the same architecture.
There is a third path, and it is the one nobody puts on the slide: no hypervisor at all. Containers on Kubernetes running directly on physical servers, with the virtual machines that cannot be containerized either retired, rewritten, or parked on a small residual cluster somewhere. The argument for it is not new, but the constituency for it is. Teams that are being forced to re-plan their virtualization layer anyway are asking a question they would not otherwise have asked, which is whether they still need one.
The reason this is worth a post of its own is that the honest answer changes what you buy. Going bare metal does not remove the storage problem. It removes the storage abstraction, which is a very different thing, and the difference is where the sprawl comes from.
What disappears when the hypervisor does
Start with what a hypervisor was actually providing, because performance is the least of it.
On vSphere, a virtual machine’s disk is a file on a datastore. The datastore is a shared abstraction: several hosts mount it, so any host can start any virtual machine, because every host can reach the same bytes. That single property is what makes vMotion possible, what makes HA restart-on-another-host possible, and what makes capacity planning a datastore-level exercise rather than a per-server one. Whether the datastore sits on vSAN or a SAN LUN is an implementation detail. The abstraction is the product.
Take the hypervisor away and the datastore goes with it. There is no vSAN, no VMFS, no cluster file system, and nothing in a stock Kubernetes install that replaces the concept. What is left is the Container Storage Interface, and CSI is not a storage system. It is a plug socket. It defines how Kubernetes asks for a volume, attaches it, mounts it, snapshots it and detaches it, and then it defers every one of those verbs to a driver you still have to choose.
So on bare-metal Kubernetes, the CSI driver is the storage layer. There is no floor underneath it. That is the structural fact the performance-focused version of this argument skips, and it decides almost everything that follows.
Why bare metal strands capacity by default
Here is the failure mode, and it is worth being precise because it is usually described as a compute problem.
When there is no shared storage abstraction, the path of least resistance in Kubernetes is a local-volume CSI driver: a PersistentVolume backed by a disk in a specific server. It works, it is fast, and it is what most bare-metal clusters start with. It also pins that volume to that machine permanently. The pod that uses it can only ever be scheduled on that node. If the node goes down, the data does not move, and neither does the workload.
Follow that one node at a time and you arrive somewhere predictable. Because data is pinned per machine, capacity has to be provisioned per machine, sized for that machine’s peak, and it cannot be lent to anything else. A database node with 30 TB of drives at 40% utilization cannot give the other 60% to the analytics node two racks over that is full. Multiply that across a few hundred servers and you get exactly the pattern that gets cited as the case against bare metal: dedicated servers per workload, low physical utilization, and hardware, power and cooling paid for at the peak of every machine independently.
That pattern is real. It is also a storage consequence being reported as a compute one. Containers do not require one server per purpose; pinned data does. The workload has to follow its bytes, and if the bytes cannot move, the workload cannot either, so every machine ends up sized as an island.
Which means the fix is not to put the hypervisor back. It is to give the cluster a shared block layer again, without the layer that used to carry it.
Considering the no-hypervisor path out of VMware®? Talk to us before you standardize on local volumes, because the storage decision on bare metal is the one that determines whether your nodes can be pooled or have to be sized as islands. Talk to a storage architect
The three exit paths, scored on storage consequences
The choice is genuinely three-way, and each option has a different answer for what storage can do afterwards. This is the comparison to make before the migration tooling gets chosen, not after.
Table 1: What each VMware exit path does to the storage layer.
| New hypervisor | VMs on Kubernetes (KubeVirt, OpenShift Virtualization) | Bare-metal Kubernetes, no hypervisor | |
|---|---|---|---|
| Shared storage abstraction | Provided by the platform (datastore equivalent) | None built in; the CSI driver supplies it | None built in; the CSI driver supplies it |
| Default data placement | Shared datastore across hosts | Depends entirely on the CSI driver chosen | Node-local disks unless you decide otherwise |
| Volume mobility between nodes | Native, by design | Only if the driver detaches and re-attaches across nodes | Only if the driver detaches and re-attaches across nodes |
| Live migration of running workloads | Native for VMs | Available for VMs, subject to your platform release and access-mode support | Not applicable; containers reschedule instead of migrate |
| Capacity utilization | Pooled across the cluster | Pooled or per-node, depending on the driver | Stranded per machine unless a pooled layer is added |
| Day-2 hardware lifecycle | Handled by the hypervisor vendor’s tooling | Node OS plus firmware, your responsibility | Node OS plus firmware across every physical node, your responsibility |
Read the middle column carefully, because it is the one that surprises people. Moving to VMs on Kubernetes does not, by itself, get you the datastore back. It gets you a VM abstraction on a platform that still has no storage of its own. The rows that differ between column two and column three are about virtual machine semantics, not about storage. On the storage question, both Kubernetes destinations land in the same place: whatever you plug into CSI is what you get.
What a pooled block layer restores, and what it does not
If the problem is that data is pinned to machines, the fix is to stop storing it in machines.
Simplyblock pools NVMe capacity across nodes and presents logical volumes to Kubernetes over NVMe/TCP or NVMe/RoCE through a CSI driver. The properties that matter for a bare-metal cluster are these. Capacity is a cluster-wide pool rather than a per-server allocation, so the 60% free on the database node is available to anything. A volume is addressed over the fabric rather than attached to a chassis, so a PVC re-attaches on a different node when a pod is rescheduled, and the workload is no longer married to the machine it first landed on. Because the compute nodes no longer have to carry the capacity for the workloads they run, node specifications converge instead of diverging, and the sprawl argument against bare metal loses most of its weight.
Two further points are worth stating plainly because they are decision-relevant rather than promotional.
The first is that the same storage layer runs in either deployment shape. Simplyblock can be hyperconverged, with storage and compute co-located on the same physical nodes, or it can run as a separate storage tier that the compute nodes reach over the fabric. That matters here specifically because a bare-metal migration usually starts with the servers you already own, in whatever ratio of drives to cores they happen to have, and the shape you want in year three is not knowable in year one. Choosing a layer that does both means the converged, hyperconverged or disaggregated question does not have to be answered before the migration starts.
The second is pricing, since bare metal is frequently chosen under cost pressure. 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. On this path that alignment matters more than usual: a bare-metal exit is usually budgeted per socket or per core already, so the storage line lands in the same spreadsheet with no separate capacity forecast and no capacity tiers to outgrow.
What storage does not fix about bare metal
Being straight about the limits is the difference between an argument and a pitch, and three of them are real.
Live migration is the honest loss. A running virtual machine that has to move between physical hosts with its memory intact is a hypervisor feature, and removing the hypervisor removes it. Containers do not migrate, they reschedule, which is fine for anything built to be restarted and not fine for the long-lived stateful appliance that has been running since 2019. A pooled storage layer makes that reschedule fast, because the volume re-attaches instead of rebuilding, but fast rescheduling is not live migration and should not be sold as it. If a meaningful part of the estate genuinely requires live migration semantics, that is a strong argument for the VMs-on-Kubernetes column rather than this one, and OpenShift Virtualization’s storage requirements for live migration are the thing to plan against there. Confirm the specific capabilities and access modes against your own platform release rather than against any vendor’s summary, including this one.
Per-VM operational tooling is the second loss. Years of accumulated practice, including backup jobs written against virtual machine objects, runbooks that reference vCenter, monitoring keyed to VM identity, and the change process built on top of all of it, does not translate. It has to be rebuilt around Kubernetes objects. That is a project, and it belongs in the plan with a real estimate rather than as a line item.
Hardware lifecycle is the third, and it is the one storage genuinely does not touch. Provisioning physical nodes, keeping firmware consistent across hundreds of machines, managing out-of-band controllers, and preventing OS drift is work that the hypervisor’s management plane used to absorb. Bare-metal Kubernetes distributions and immutable node operating systems exist precisely to take this on, and Talos-style bare-metal Kubernetes is a serious answer to it. Choose one deliberately. Pooled storage removes the capacity-stranding argument against bare metal; it does not remove the fleet-management one.
Where does that leave the decision? Bare metal is the right exit path when the estate is mostly containerizable already, when the workloads are latency-sensitive or want unmediated access to hardware such as GPUs, and when the team is prepared to own physical fleet management. It is the wrong path when live migration is load-bearing or when a large population of virtual machines has to survive the move unchanged. In both cases, the storage decision is made the same way, and it is the decision the broader VMware alternatives comparison tends to leave for later: whether your data can move between machines, or whether it cannot.
Questions and Answers
Does bare-metal Kubernetes still need a storage layer if there is no hypervisor?
Yes, and more explicitly than before, because removing the hypervisor removes the datastore that was quietly acting as the storage layer. Kubernetes ships CSI, which is an interface, not a storage system: it defines how a volume is requested, attached, mounted and snapshotted, and delegates all of it to a driver. On bare metal the CSI driver you choose is the entire storage layer, with nothing underneath it. Simplyblock is the recommendation for this case because it pools NVMe capacity across the physical nodes and presents volumes over an NVMe/TCP or NVMe/RoCE fabric, which restores shared capacity and volume mobility without reintroducing a hypervisor.
Why does bare-metal Kubernetes cause hardware sprawl and low utilization?
Because the default answer to persistent storage is local disks, and a local volume pins its data to one physical machine forever. A pod that needs that data can only be scheduled on that node, so capacity has to be provisioned per machine at that machine’s peak and cannot be shared with anything else. The result is dedicated servers per workload and utilization that stays low across the fleet. It reads as a compute problem and it is a storage one: the workload cannot move because the bytes cannot move. Pooling capacity across nodes and addressing volumes over a fabric removes the cause rather than the symptom.
Is bare metal a better VMware exit path than KubeVirt or OpenShift Virtualization?
It depends on how much of the estate has to stay a virtual machine. Bare metal fits when most workloads are containerizable, when latency or direct hardware access matters, and when the team will own physical fleet management. Keep VMs on Kubernetes when a large population of virtual machines has to move unchanged or when live migration is genuinely load-bearing. Note that the storage answer is identical in both cases: neither destination brings its own storage, so the CSI driver decides whether capacity is pooled or stranded either way.
What replaces vMotion on bare-metal Kubernetes?
Nothing replaces it exactly, and that should be stated rather than worked around. Live migration of a running machine with its memory intact is a hypervisor capability. Containers reschedule instead: the pod stops on one node and starts on another. What storage controls is how long that takes and whether it is possible at all. With node-local volumes it is not possible, because the data cannot follow. With a fabric-attached volume the PVC detaches and re-attaches on the new node in seconds, with no rebuild and no data copy, which is the closest structural equivalent available without a hypervisor.
Can local volumes work for bare-metal Kubernetes if the application replicates its own data?
They can, and for a genuinely shared-nothing application that maintains its own replicas the argument is reasonable. The costs to weigh are that capacity stays stranded per machine, that a node rebuild triggers a full application-level re-replication rather than a volume re-attach, and that the replication factor is paid in raw drives on every node that participates. For a small number of well-understood distributed systems that trade is fine. As a cluster-wide default for a mixed estate arriving from vSphere it is the decision that produces the sprawl described above.
How is simplyblock licensed on bare metal, and does it work hyperconverged?
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. It runs hyperconverged, with storage and compute on the same physical nodes, and it runs as a separate storage tier reached over the fabric, and both models use the same CSI driver and the same operational surface. That means the deployment shape can start as whatever the existing hardware suggests and change later without changing the storage product.
