What Replaces VMware HA, DRS, and Fault Tolerance When You Leave vSphere

A VMware® exit gets planned as a platform decision and lands as a features decision. The hypervisor comparison is the easy part, and it is the part every migration guide covers. What nobody hands you is the list of cluster features your availability design quietly depends on, and what each one becomes on the other side.

For most estates that list is six items long. vSphere HA, to bring VMs back after a host dies. DRS, to keep load spread across hosts without anyone watching. Storage DRS, to keep datastores from filling unevenly. Fault Tolerance, for the handful of workloads that cannot tolerate a restart at all. Site Recovery Manager, renamed VMware Live Site Recovery under Broadcom, to orchestrate a site failover. And vSphere Replication underneath it, moving the bytes.

Three of those translate cleanly, one translates into somewhere unexpected, one mostly stops existing, and one has no equivalent whatsoever. The interesting result is which category each lands in, because the feature that looks most like a compute feature turns out to be the one that is decided entirely by your storage layer. This post is the second in a short series: the vMotion and Storage vMotion translation covers the mobility half, this one covers availability, and the VDI desktop translation covers the desktop half of the estate.

The feature-by-feature answer

Take the six features an availability design actually rests on and translate them individually, scoring each on what it needs from storage rather than on what it is called.

Table 1: The six vSphere availability features most likely to be missing from a destination-platform runbook.

Two rows deserve to be read before the rest. The first row is the one that decides whether your availability design works at all, and it is a StorageClass decision masquerading as a platform feature. The fourth row is the one to be honest about early: nothing on the destination platform runs a shadow copy of your VM in lockstep, and a post that pretends otherwise is not worth reading.

The DRS row is worth a warning too. It is a scheduling answer, not a storage answer, and any storage vendor claiming to replace DRS is describing something else. What storage does contribute there is narrower and worth stating precisely, which the third section does.

vSphere HA was a storage feature wearing a compute name

Ask a vSphere admin what HA does and the answer is about hosts: a host fails, the cluster notices, the VMs that were running on it start again somewhere else. Ask why that is possible and the answer is about storage. The surviving host can boot that VM because it already has the VM’s files open to it. Every host in the cluster mounts the same datastores, so a failover involves no data movement at all. The disk was never anywhere near the host that died, in any sense that mattered.

The storage dependency is not incidental, either. It is wired into the failure detection. Beyond the management network, HA uses datastore heartbeating as a second channel, specifically so the cluster can tell a genuinely dead host apart from one that is merely isolated on the network. A shared datastore is not just where the VM lives; it is part of how the cluster decides whether to restart it. Admission control then reserves the failover capacity, whether as a percentage of cluster resources, as slots, or as dedicated failover hosts, so that the restart has somewhere to land.

Note what HA is not, because this matters for the Fault Tolerance discussion later. HA is a restart. The guest boots again, in-flight state is gone, and anything holding an open connection notices. It buys you recovery time, not continuity.

The same intent on KubeVirt has one extra step, and it is the storage step

On KubeVirt, and on Red Hat® OpenShift® Virtualization built on top of it, a VM’s disks are PersistentVolumeClaims. A VirtualMachine with runStrategy: Always is declaring the same intent HA expressed: this VM should be running, and if it stops, bring it back. The controller will recreate the VM instance on another node.

Then the volume has to follow, and this is where the translation stops being a rename.

When a node dies, the kubelet on it dies with it. Nothing on that node will ever unmount the volume or acknowledge a detach, because there is nothing left running to do so. The VolumeAttachment for that PVC still says the volume belongs to a node that no longer answers. If the volume is ReadWriteOnce, the replacement VM cannot get it: the new pod sits in ContainerCreating and the events show the multi-attach error: the volume reports itself already attached elsewhere, and the elsewhere in question is a node that will never answer again. From the operator’s seat, HA appears to have silently not happened.

Kubernetes has a defined answer for this, and it is worth knowing by name because it is the piece most VMware-exit runbooks are missing. The non-graceful node shutdown path uses the node.kubernetes.io/out-of-service taint: once something has confirmed the node is genuinely down and applies that taint, the attach and detach controller stops waiting for a cooperative unmount, force-detaches the volumes, and lets the workload be rescheduled. The word doing the work in that sentence is “confirmed.” Something has to fence the node first, because force-detaching a volume from a host that is actually alive and still writing is how you corrupt a filesystem. That is the job vSphere HA was doing with datastore heartbeats and host isolation responses, and on Kubernetes it lands on node health checking and remediation, surfaced on OpenShift as MachineHealthCheck and the node health check and fencing operators. It is a real component you have to deploy and tune, not a checkbox you inherit.

There is a second path, and it is the better one. If the volume is ReadWriteMany in block mode, the attach on the surviving node is not blocked by the stale one. The replacement VM can claim the disk and boot while the dead node’s attachment is still being reconciled, because a volume that two nodes are allowed to hold at once has nothing to wait for. Recovery time collapses back to guest boot time, which is what a vSphere admin expects HA to cost.

This is the same StorageClass property that KubeVirt live migration requires, and it is the reason the two features are one decision rather than two. Choose RWX block volumes and you get live migration for host patching and fast failover for host death from a single choice. Accept the node-local RWO default and you lose both, with no warning at provisioning time and no error until the first real failure. Our post on OpenShift Virtualization storage architecture covers the RWX block mechanics in detail, and the KubeVirt persistent storage guide covers how those volumes get defined in the first place.

DRS is a scheduler, Storage DRS is designed out, and Fault Tolerance has no answer

The remaining three features fail in three different ways, and lumping them together is how migration plans end up with a hole in them.

DRS maps onto scheduling, not storage. In vSphere it watches CPU and memory contention across hosts and quietly moves running VMs with vMotion to even things out, governed by an automation level and a migration threshold, and in recent releases scored per workload rather than per cluster. The Kubernetes counterpart splits in two: kube-scheduler decides where a workload starts, and the descheduler project handles the ongoing part, evicting workloads from nodes that have drifted out of balance. Eviction normally means a restart, which is a downgrade from what DRS did, so there is one detail worth wiring up. Setting evictionStrategy: LiveMigrate on the VM tells KubeVirt to satisfy an eviction request with a live migration instead of a shutdown. That combination gets you close to DRS behaviour: something notices the imbalance, and the VM moves without the guest noticing. Its precondition is the same RWX block volume from the previous section, which is the only contribution storage makes here. Everything else is a platform-team concern, and the existing translation work in our post on platform engineering after the VMware exit maps the DRS resource limits onto quotas.

Storage DRS mostly stops existing, for the same reason Storage vMotion did. It balanced VMs across datastores by space consumption and observed I/O latency, remediating with a Storage vMotion each time. One network-attached NVMe pool has no datastores to balance and no per-datastore fill level to chase, so the requirement is not met differently, it is designed away. What remains is capacity management inside the pool, which is the storage layer’s own business rather than a VM operation.

Fault Tolerance has no equivalent, and this is the honest answer. FT ran a second copy of the VM on another host in lockstep, kept synchronised closely enough that a host failure meant the shadow simply continued, with no restart and no lost state. Nothing in KubeVirt does this. There is no lockstep execution, no shadow VM instance, no continuous checkpointing of guest state to a peer node, and no storage product changes that, because it was never a storage feature. FT was also narrow in vSphere itself: it capped vCPUs per protected VM, limited how many protected VMs a host could carry, wanted a dedicated low-latency logging network, and required HA on the cluster. It protected against host failure, never against a crash inside the guest.

So the requirement survives the migration and the feature does not, which turns it into a design question. For the workloads that were on FT, the replacement is redundancy above the VM rather than beneath it: run more than one instance, let the application layer handle failover, and size the availability budget around a restart rather than a continuation. If a workload genuinely cannot survive a restart and cannot be made redundant at the application layer, that is worth discovering during planning rather than during the first node failure. It is also worth checking how many VMs were actually on FT, because in most estates the answer is a very small number, and the honest scope of the problem is smaller than the missing feature makes it sound.

Rebuilding an availability design without HA, DRS, and Fault Tolerance to lean on? Talk to us while the StorageClass decision is still open, because it is the one that decides whether failover works. Talk to a storage architect

The DR half, and what the storage layer has to provide

Site Recovery Manager, now VMware Live Site Recovery, was never doing the replication itself. It orchestrated: protection groups, recovery plans, non-disruptive test failovers, planned migration, reprotect. The bytes moved underneath, either through vSphere Replication as a host-based per-VM appliance or through array-based replication driven by a storage replication adapter.

That split is exactly how it translates, and it translates well. The orchestration half becomes declarative: the manifests describing your VMs, networks, and volume claims live in Git, so recovering them at another site is applying known configuration rather than replaying a click-path, and the recovery plan becomes something you can diff and review. The replication half belongs in the storage layer, as asynchronous replication of the volumes plus promotion of the secondary copy at the recovery site. Our post on Day 2 storage operations after the VMware exit covers that workflow, along with the snapshot and observability mechanics around it, so this post links there rather than repeating it. For the VM-level backup and restore path specifically, the KubeVirt backup and restore guide is the closer match. The RTO and RPO numbers you agreed to in the vSphere design carry over unchanged, and they are the right way to specify the replacement.

The four things storage has to do for any of this to hold

Line up the failure events against what each one now needs, and one column carries the weight.

Table 2: Five availability events, and the storage capability each one actually depends on.

Three of those five rows want the same thing, which is a volume whose identity is not tied to one host. That is what a pooled storage layer addressed over NVMe/TCP or NVMe/RoCE provides by construction rather than by configuration. There are no datastores to mount, because every node on the fabric can address the volume already, and simplyblock hands out ReadWriteMany block volumes without a clustered filesystem layered on top, so the surviving node’s attach is not queued behind a detach that a dead kubelet will never perform. The restart is bounded by how long the guest takes to boot, which is the property vSphere admins are actually asking about when they ask what replaces HA. Live migration and descheduler-driven rebalancing come out of the same decision, and volume-level asynchronous replication with promotion at the secondary site covers the bottom row.

Two structural properties matter more here than they do elsewhere in a VMware exit, because vSphere charged for availability in compute. Admission control worked by reserving a slice of the cluster you were not allowed to use, and Fault Tolerance doubled the host footprint of every VM it protected. Both cost cores. 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 same volumes stay addressable whether the hypervisor above is vSphere today, KubeVirt or OpenShift Virtualization next year, or bare-metal Kubernetes alongside both, so the availability design does not have to be rebuilt again at the next platform move.

Two limits are worth stating plainly, because a storage layer that claims to cover everything here is overclaiming. Fencing is not a storage function. Something in the platform has to decide that a node is genuinely dead, and that component is yours to deploy and test, no matter what sits underneath. And Fault Tolerance stays gone. The requirement has to be met above the VM, in the application, or it has to be renegotiated.

Which is the short answer to the question in the title, and it is four different answers. vSphere HA is replaced, and whether the replacement works is decided by your StorageClass and your fencing story. DRS is replaced above the storage layer, by the scheduler and the descheduler, with live migration keeping it non-disruptive. Storage DRS is designed out. Fault Tolerance is gone, and the workloads that depended on it need a new plan rather than a new feature. If you want the mobility half of this translation, the vMotion and Storage vMotion post is the companion piece, and the KubeVirt and VMware comparison is the wider platform view.

Questions and Answers

What replaces vSphere HA on KubeVirt or OpenShift Virtualization?

A VirtualMachine with runStrategy: Always, plus node health checking and fencing, plus a volume the surviving node can actually attach. The first part is trivial and the third part is where HA replacements fail. A node-local ReadWriteOnce volume stays attached to the dead node until something force-detaches it, so the restart stalls on a multi-attach error. With simplyblock the volume is addressed over NVMe/TCP from a pool rather than mounted per host, and ReadWriteMany block access means the new node attaches immediately, so recovery time is guest boot time instead of a detach timeout plus boot time. You still need the fencing component, because deciding a node is genuinely dead is a platform job, not a storage one.

Is there a DRS equivalent in Kubernetes?

Yes, split across two components, and it is a compute answer rather than a storage one. kube-scheduler handles initial placement, and the descheduler handles the ongoing rebalancing that DRS automated. The one thing worth adding is evictionStrategy: LiveMigrate on your VMs, which makes KubeVirt satisfy a descheduler eviction with a live migration instead of a restart. That needs the same RWX block volume live migration needs, so if you have made the storage decision correctly for host patching, DRS-like rebalancing costs you nothing extra. Be sceptical of any storage product claiming to replace DRS itself.

What is the equivalent of VMware Fault Tolerance?

There is none, and that is the accurate answer rather than a hedge. Fault Tolerance ran a lockstep shadow copy of the VM on a second host so that a host failure caused no restart and no lost state, and KubeVirt has no mechanism of that shape. No storage layer changes this, because FT was never a storage feature. The practical replacement is redundancy above the VM: run multiple instances, let the application handle failover, and design the availability budget around a fast restart. Worth checking how many VMs were genuinely on FT before treating this as a blocker, since in most estates the list is very short.

What replaces Storage DRS after a VMware exit?

Nothing above the storage layer, and it should not need replacing. Storage DRS balanced VMs across datastores by space and latency, remediating with a Storage vMotion, and that whole problem is a consequence of capacity being partitioned into datastores welded to hosts. On a pooled layer over NVMe/TCP there are no datastores to balance and no per-datastore fill level to chase, and QoS is a property of each volume rather than a side effect of which VMs share a LUN. If your vSphere design leaned on automatic datastore balancing, satisfy that dependency underneath Kubernetes rather than looking for a controller above it.

What replaces Site Recovery Manager and vSphere Replication?

Split them the way they were always split. The orchestration that Site Recovery Manager, now VMware Live Site Recovery, provided becomes declarative configuration: manifests in Git that can be applied at the recovery site, reviewed, and tested, rather than recovery plans held in a management appliance. The replication becomes storage-layer asynchronous replication of the volumes with promotion of the secondary copy, which is where it belongs and where it stops being per-VM work. Simplyblock does the replication and snapshot half at volume level, so the same mechanism serves both the DR path and Day 2 snapshot operations, and your existing RTO and RPO commitments remain the right specification.

Do I need shared storage for VM high availability on Kubernetes?

VM high availability needs something with the same property, which is a volume that is not tied to one host. It does not have to look like a shared datastore, and on Kubernetes it should not. A pooled storage layer addressed over NVMe/TCP or NVMe/RoCE gives every node access to the volume across the fabric without any host mounting anything, which satisfies the precondition vSphere HA depended on while keeping compute and capacity independently scalable. The failure mode to avoid is the node-local default StorageClass, which looks fine in testing and quietly makes both live migration and host-failure recovery impossible.