For restarting VMs after losing a server, Proxmox HA is an alternative to VMware HA. The project changes when production also relies on guest OS monitoring, enforced capacity reserves or restart dependencies. Those protections need individual examination.
A cluster mainly using recovery after hardware failure may therefore find Proxmox a suitable answer. A platform relying on advanced vSphere HA automation requires more architectural work. That difference affects migration cost, scheduling and operating procedures.
This episode of the VMware Exit series uses vSphere HA 8.x and Proxmox VE 9.2 as references, with documentary scope detailed below. It compares recovery through restart; VMware Fault Tolerance and uninterrupted application continuity are outside that scope.
What transfers, what changes
| Protection | VMware vSphere HA | Proxmox HA |
|---|---|---|
| Host failure | Restarts protected VMs | Recovers resources registered with HA |
| Cluster isolation | Configurable VM response | Quorum and node self-fencing |
| Frozen guest OS | VM Monitoring, when enabled | No equivalent recovery from the HA state check alone |
| Spare capacity | Admission Control | Headroom maintained through sizing and operations |
| Restart order | Priorities and group dependencies | Placement affinity, without equivalent sequencing |
| Lost storage paths | VMCP APD/PDL policies | Behaviour linked to storage and resource state |
Actual use of these features is decisive. An available but disabled VMware option is not a protection that needs rebuilding.
A server powers off: both platforms can recover VMs
Take a straightforward case: three hosts, disks accessible from survivors and enough capacity to absorb the failure. A server powers off suddenly. Its VMs stop with it.
vSphere HA uses FDM agents on ESXi hosts. A primary agent coordinates protection and requests VM restarts on surviving hosts. In Proxmox, the cluster HA manager makes the decision and local managers execute actions. Recovery waits for the previous node's state to be secured against concurrent execution.
The delivered service is comparable: protected VMs can restart elsewhere without waiting for server repair. Lost memory is not recovered. The guest OS boots, followed by application recovery, including any database recovery work.
Protected scope needs different attention, however. In vSphere, HA protects cluster VMs according to settings and exceptions. In Proxmox, VMs and containers must be explicitly assigned to HA management. Adding a host to the cluster does not automatically protect every workload on it.
For a business primarily requiring this recovery, Proxmox covers the essential function. Accessible disks, consistent networking and remaining capacity are requirements shared by both architectures. Live migration during maintenance uses a different mechanism.
A host stays powered on but loses the cluster: interruption can spread
Now consider a host losing cluster communication while its VMs retain their disks and application networking. Users may continue working while the hypervisors lose coordination.
VMware HA uses several signals: FDM network communication, datastore heartbeats where available and isolation detection addresses. Depending on configuration, isolation response can leave VMs powered on, power them off or attempt shutdown before recovery. Losing a network signal does not therefore systematically require an ESXi reboot.
Proxmox uses Corosync quorum to authorise cluster decisions. When a node loses quorum with active HA resources, its watchdog mechanism can trigger self-fencing: the entire server reboots.
That scope changes the incident. VMs outside HA management on the same host also stop; automatic recovery elsewhere is not assured for them. Continued application network connectivity does not protect them from this reset.
VMware isolation choices must therefore be revisited in the Proxmox design. This affects Corosync paths and placement of protected and unprotected workloads. In a two-node cluster, a QDevice can provide an external arbitration vote. It adds neither disk copies nor compute capacity.
Like the previous scenario, this example is illustrative. It explains an architectural difference without claiming a customer incident or measured recovery time.
A “running” VM can have a frozen guest OS
Monitoring scope is another concrete difference. With VM Monitoring enabled, VMware can use VMware Tools heartbeats and I/O activity to decide whether to reset a VM whose OS has stopped responding. The physical server may be healthy.
Proxmox HA's VM check concerns execution on the hypervisor. The published implementation does not test business service or guest OS health. It follows that a frozen guest whose QEMU process remains considered running may trigger no HA action.
External monitoring or a guest-level mechanism can extend protection. Installing QEMU Guest Agent alone does not recreate VMware's VM Monitoring policy.
The migration issue is specific: if VM Monitoring currently contributes to application recovery, decide how to retain that coverage. If it is disabled, the requirement differs. On either platform, a healthy OS signal does not prove that a business transaction succeeds.
Capacity reserves and restart order can disappear quietly
Admission Control and restart dependencies attract less attention than a host failure. Their absence may nevertheless become apparent during the first incident.
Admission Control can reject a power-on that would compromise VMware's failover reserve, according to configured policy and reservations. Proxmox CRS selects placement and can balance resources; this does not enforce an N+1 reserve when admitting new workloads. The Dynamic Load Balancer introduced in VE 9.2 does not change that distinction.
A cluster can consequently accommodate VMs during normal operation and then lack RAM on recovery hosts. Headroom needs capacity rules and review as the estate evolves.
Sequencing raises a different issue. VMware HA provides priorities and dependencies between VM groups, with conditions such as detecting guest heartbeats. Proxmox affinity governs where resources run; it does not mean an application waits for its database.
Proxmox documentation also states that HA-managed VMs do not follow ordinary Boot Order. Setting that order does not preserve a VMware dependency chain. For a multi-tier application, services need to tolerate unavailable dependencies, or orchestration must handle recovery.
Even on VMware, a guest heartbeat does not establish that a database already accepts connections. Application availability needs attention beyond VM startup.
When disks become inaccessible, HA alone is insufficient
VMware provides VM Component Protection, or VMCP, for configured responses to storage path loss: APD, All Paths Down, and PDL, Permanent Device Loss. Conservative and aggressive APD modes govern differently whether a VM is stopped for attempted recovery.
Proxmox HA does not directly reproduce these policies. It can handle a failed start or a resource detected as stopped and attempt another node. A VM still considered active but stalled on I/O may remain outside that case.
Storage loss without quorum loss does not therefore necessarily trigger fencing or the expected recovery. Storage type, path redundancy and how the fault manifests also determine the result. A forthcoming episode in the VMware Exit series will compare vSAN and Ceph to examine this protection layer.
What this means for your VMware exit
Proxmox HA is a coherent choice when the objective is automatic recovery after host failure on an appropriately sized architecture. It also covers Linux containers managed by Proxmox. For this scope, additional VMware features alone are insufficient reason to rule out the target.
When production depends on VM Monitoring, Admission Control, VMCP or application restart rules, include these differences in project scope and costing. Adaptation may be reasonable; it needs an owner and a place in future operations.
Planning a migration to Proxmox? VSHIFT Solutions helps you identify the HA protections to retain and validate recovery on the target architecture.
References and limits
Documentary analysis as of 15 October 2026, without a recovery-time benchmark. VMware scope is vSphere HA 8.x; some knowledge-base articles also cover 7.x or the FDM architecture in VCF 9.0. The Proxmox reference is VE 9.2, with project documentation version 9.2.13. Project links below pin the reviewed revisions; match features and settings to installed versions.
- Broadcom: FDM agents, failures and isolation, VM Monitoring.
- Broadcom: Admission Control, restart dependencies, VMCP policies.
- Proxmox: HA manager and fencing, Boot Order, quorum and QDevice.
- Proxmox: VM state check in HA manager 5.2.5, VE 9.2 dynamic balancing.