VMware ESXi and vSphere Cluster Management

vSphere Fault Tolerance (FT) Explained

Learn how VMware vSphere Fault Tolerance protects critical VMs, how FT differs from HA, its requirements, limitations, capacity impact, and operational workflow.

What Is vSphere Fault Tolerance?

vSphere Fault Tolerance (FT) is a vSphere availability feature that protects an individual virtual machine (VM). FT runs a primary VM and a synchronized secondary VM on separate ESXi hosts. If the host running the primary fails, the secondary can immediately become the active VM.

The purpose of FT is to maintain service availability during covered ESXi host failures. It is intended for workloads where a restart interruption or loss of in-memory and uncommitted transaction state is unacceptable or must be minimized.

FT is not a replacement for backups, disaster recovery, or application-level high availability. It primarily addresses the failure of a supported host or protected VM execution instance.

Key FT Terms

Primary VM: The active VM instance that is currently serving the workload.
Secondary VM: The synchronized counterpart running on another compatible ESXi host.
Execution state: The running state of a VM, including its in-memory processing context.
Failover: The transition of workload execution from a failed primary to the secondary.
FT logging network: The network path used to exchange synchronization traffic between participating hosts.
Cluster admission control: Capacity control that helps ensure sufficient resources remain available for protected workloads and recovery conditions.

How vSphere FT Works

An administrator enables FT for an eligible VM in a compatible vSphere cluster.
vSphere creates or starts a secondary VM on a different ESXi host.
The primary and secondary execute the workload in a synchronized manner. VM execution state is continuously transmitted between the participating hosts.
The primary continues serving users and applications while the secondary remains ready to take over.
If the primary host or primary VM fails in a covered scenario, the secondary becomes active automatically.
vSphere can establish a replacement secondary so that the workload has continued FT protection after the takeover, provided sufficient compatible capacity is available.

The important distinction is that FT preserves synchronized running state instead of waiting for a VM to boot after a failure. This is why FT can avoid the normal restart interval associated with host-failure recovery.

FT Compared with vSphere HA

vSphere High Availability (HA) is a cluster-level availability feature. When HA detects an ESXi host failure, it generally restarts affected VMs on surviving hosts. This protects many workloads, but the VM must boot again and applications must recover.

FT maintains a live secondary VM. During a covered failure, the secondary takes over rather than waiting for a normal VM restart. Because the secondary receives execution state continuously, FT can preserve more in-memory processing context and reduce the interruption window.

Characteristic	vSphere Fault Tolerance	vSphere HA
Protection model	A synchronized primary and secondary VM protect one selected workload.	Cluster-level recovery protects VMs by restarting them on surviving hosts.
Recovery method	Automatic takeover by the secondary VM.	Detection of failure followed by VM restart.
Expected interruption	Designed to avoid the normal restart interval, subject to the failure and configuration.	Includes host-failure detection, placement, boot, and application recovery time.
In-memory state preservation	Seeks to preserve synchronized execution state.	Usually loses volatile in-memory state when the VM restarts.
Data-loss exposure during host failure	Historically intended to avoid loss of covered transactions, subject to supported operation.	Uncommitted or in-flight work may be lost during restart.
Resource overhead	Requires capacity for both running VM copies plus synchronization overhead.	Requires cluster failover capacity, but does not normally run a second copy of every protected VM.
Typical workload fit	Selected critical workloads that cannot tolerate a restart and justify duplicate resource use.	Broad protection for workloads that can tolerate recovery time.
Scope of protection	Primarily covered host or protected VM execution failures.	Primarily cluster-level VM recovery after host failure.

FT is commonly used inside an HA-enabled cluster, but the two features provide different recovery models. HA is usually the broader baseline; FT is an enhanced option for selected VMs.

When FT Is Appropriate

Business-critical applications: Use FT when even a short restart window has a significant operational or financial impact.
Small critical infrastructure services: A compact service such as a specialized coordination or licensing service may be difficult to cluster but important enough to protect continuously.
Legacy applications without native clustering: FT can provide infrastructure-level protection when the application vendor does not support application-level clustering.
Workloads with justified duplicate capacity: The cost of a second running VM, additional network traffic, and reserved host capacity must be acceptable.

Example: A Legacy Line-of-Business Application

A small line-of-business application runs on one VM and has no supported application clustering feature. If users cannot tolerate a normal HA restart, an administrator can evaluate FT. The evaluation must include compatibility, capacity, licensing, storage, and network requirements rather than assuming that every VM is eligible.

When FT Is Not the Best Fit

If an application can tolerate several minutes of recovery, HA may provide adequate and simpler protection.
If the requirement is application-aware recovery, use application clustering, database replication, or another application-level design.
If the workload is large or resource-intensive, the duplicate compute and memory allocation may reduce cluster efficiency or exceed FT limits.
If the guest operating system or application is likely to fail, FT does not create an independent healthy software instance. The same failure can be reproduced on both copies.
If protection must cover a site outage, ransomware, accidental deletion, or long-term data recovery, use backups and disaster-recovery mechanisms in addition to availability features.

Resource and Capacity Impact

FT requires compute and memory resources for both a primary and a secondary copy. A VM configured with 2 GB of memory requires a corresponding 2 GB allocation for its secondary, in addition to host, virtualization, synchronization, and recovery overhead.

Capacity planning must consider:

CPU: Both hosts need sufficient processing capacity for the workload and synchronization operations.
Memory: The cluster must accommodate both VM memory allocations and retain enough headroom for host failure and secondary placement.
Storage: The participating hosts must have access to the required VM files through shared storage or another storage configuration supported by the deployed release.
Network: FT logging and synchronization traffic requires a suitable path with adequate bandwidth, low contention, and appropriate connectivity.
Host placement: The primary and secondary must run on different ESXi hosts. A secondary on the same host would not protect against that host's failure.
Admission control: Cluster policies should preserve enough capacity to keep protected workloads running and to create or re-establish a secondary after a host event.

Simple Memory Example

Suppose a protected VM is configured with 2 GB of memory. The design must provide capacity for approximately two 2 GB VM memory allocations, one for the primary and one for the secondary, plus normal virtualization overhead and failover headroom. This does not mean that memory is the only planning concern; CPU, storage, network traffic, and host placement are also required.

Requirements and Version Dependence

FT requirements vary significantly between vSphere releases. Always validate the exact release, edition, ESXi build, hardware generation, and virtual hardware configuration against the applicable VMware compatibility documentation and licensing terms.

Common areas to verify include:

Area	What to verify	Why it matters	Version-specific considerations
Licensing or edition	Confirm that the deployed vSphere license includes the required FT capability.	Unsupported licensing can prevent enablement or limit available features.	Entitlements vary by release and edition.
ESXi hosts	Use supported and compatible ESXi hosts in the same eligible cluster.	The primary and secondary require compatible host capabilities.	Supported combinations depend on the vSphere release and hardware.
CPU and virtual hardware	Check CPU compatibility, EVC or related compatibility settings, and virtual hardware support.	Incompatible execution environments can prevent synchronization.	Rules and supported configurations change over time.
vCPU count	Verify the supported number of virtual CPUs for the specific release.	FT has workload-size and configuration limits.	Earlier implementations were limited to single-vCPU VMs; later releases expanded supported vCPU counts and configurations.
Storage	Confirm datastore visibility and supported shared or alternative storage configuration.	The secondary needs access to the VM's required files.	Supported storage designs are version-dependent.
FT logging network	Configure and validate the host network path used for FT traffic.	Synchronization depends on reliable host-to-host connectivity.	Network design and feature requirements can change by release.
Cluster capacity	Reserve enough CPU, memory, storage, and placement capacity on another host.	A secondary cannot be created or maintained without eligible capacity.	Admission-control behavior and resource requirements depend on the environment.
VM snapshots	Check whether the VM has snapshots and whether the installed release supports the exact snapshot state.	Snapshots can make a VM ineligible or impose restrictions.	Do not assume that snapshot behavior is identical across releases.
Devices and VM features	Review passthrough devices, attached hardware, special virtual devices, and other compatibility-sensitive settings.	Unsupported devices or features can prevent FT protection.	The supported feature set is release-specific.

Earlier FT implementations supported only single-vCPU VMs. Later vSphere releases expanded the supported vCPU count and configuration options, but the current limit must be checked for the installed release, edition, hardware, and VM configuration. Do not apply a historical limit or a newer limit universally.

VM Configuration Restrictions

Unsupported virtual hardware, devices, or VM features can prevent FT from being enabled. Before changing a critical VM, review its vCPU count, virtual hardware version, attached devices, passthrough features, snapshots, storage layout, and network configuration.

Snapshots deserve special attention. A historical FT restriction prevented protection of VMs with snapshots in the described configuration. Snapshot support and restrictions have changed, so administrators must verify the rules for the exact vSphere version instead of assuming that snapshots are either always supported or always prohibited.

Failure Coverage and Boundaries

Failure or event	FT response or expectation	Additional protection needed
ESXi host failure	For a covered and supported configuration, the secondary can become active.	Maintain compatible hosts, capacity, networking, and monitoring.
Primary VM failure	The secondary may take over when the failure is within FT's supported protection scope.	Investigate the cause and confirm that a healthy secondary is re-established.
Guest OS crash	FT does not independently repair the guest OS. The failure state may be reflected in the synchronized copy.	Use guest monitoring, patching, backups, and OS recovery procedures.
Application crash	FT does not restart or repair a failed application merely because the VM is protected.	Use application monitoring, restart policies, clustering, or vendor recovery procedures.
Data corruption	Corruption can be present in the workload state seen by both VM copies.	Use backups, integrity controls, replication, and application recovery.
Storage failure	Protection depends on the storage design and the scope of the storage failure; FT is not automatically storage redundancy.	Use resilient storage, datastore protection, backups, or replication.
Site failure	FT within one site does not inherently provide site-level disaster recovery.	Use disaster-recovery replication and a documented recovery plan.
Accidental deletion or ransomware	FT does not provide a historical clean copy or undo malicious changes.	Use protected backups, recovery points, security controls, and disaster-recovery procedures.

FT replicates execution rather than judging whether the application is making correct decisions. A faulty process, bad configuration, malware infection, or logical error can affect both copies.

Operational Workflow

Assess criticality: Determine whether the workload truly requires FT or whether HA, backup, application clustering, replication, or disaster recovery is more appropriate.
Validate the cluster: Check eligible ESXi hosts, CPU compatibility, virtual hardware, licensing, storage access, FT logging networking, admission control, and spare capacity.
Review the VM: Confirm the vCPU count, memory, snapshots, attached devices, passthrough features, and other FT restrictions for the exact release.
Enable FT: Use the vSphere Client to enable Fault Tolerance for the eligible VM.
Place the secondary: Select or allow placement on a separate compatible ESXi host.
Verify synchronization: Confirm that the secondary exists, the primary and secondary roles are correct, and FT reports healthy synchronization.
Monitor continuously: Watch FT status, synchronization health, host placement, resource consumption, alarms, and events.
Test under change control: Plan and test failure handling according to organizational procedures. Confirm that monitoring, application behavior, and secondary re-creation work as expected.

Monitoring and Administration

In vCenter Server, identify which VM instance is primary and which is secondary. Review protection status, synchronization state, secondary availability, host placement, recent events, and alarms.

Monitoring should include the supporting HA cluster, not only the protected VM. A VM may appear protected while the cluster is losing the capacity or network conditions needed to maintain its secondary. Track:

FT enabled, protected, degraded, or unavailable status.
Primary and secondary host placement.
Synchronization health and any FT logging network warnings.
Secondary VM availability and attempts to create or re-establish it.
CPU, memory, datastore, and network consumption.
HA admission-control status and available failover headroom.
Host maintenance, compatibility, and hardware events.
Recent VM configuration changes that may have introduced an unsupported feature.

Typical administrative actions include resolving compatibility errors, correcting FT logging connectivity, freeing or adding capacity, moving a secondary to an eligible host, re-establishing a missing secondary, and investigating FT-related alarms and events.

vCenter Configuration Workflow

Confirm that the VM belongs to a compatible cluster with sufficient spare capacity.
Verify that FT logging is configured on the participating ESXi hosts.
Review VM hardware, vCPU count, snapshots, attached devices, passthrough features, and other compatibility restrictions.
Use the vSphere Client to enable Fault Tolerance for the eligible VM.
Select or allow placement of the secondary on a separate compatible host.
Verify that the secondary is created and that FT reports healthy synchronization.
Monitor alarms, events, host placement, resource usage, and secondary availability after enablement.

Troubleshooting FT

Fault Tolerance Cannot Be Enabled

Likely causes include an unsupported vCPU count for the installed release, an existing snapshot or incompatible snapshot state, unsupported virtual hardware, an attached device or passthrough feature, host or CPU incompatibility, storage problems, insufficient licensing, or an invalid cluster configuration.

Start with the vSphere Client task or compatibility error. Then validate the VM and cluster against the FT requirements for the exact vSphere version. Do not resolve the problem by applying a generic vCPU or snapshot rule from another release.

The Secondary Cannot Be Created or Remains Unavailable

Check whether a different compatible ESXi host has enough CPU and memory capacity. Also check host placement constraints, datastore visibility, storage accessibility, and FT logging network connectivity. Review cluster capacity, host events, and FT-related events for the reason placement or startup failed.

FT Protection Is Degraded or Synchronization Is Poor

Investigate network congestion, latency, packet loss, host resource contention, secondary host problems, datastore issues, and recent VM or host configuration changes. Inspect FT status and events, validate the logging network, review host resource usage, and confirm that both hosts remain compatible.

The Application Is Unavailable Despite FT

Treat this as a guest or application recovery issue if the guest OS crashed, the application failed, data was corrupted, a logical error occurred, or the event was outside FT's scope. Use application monitoring, backups, replication, clustering, or disaster-recovery procedures as appropriate.

FT, HA, Backups, and Disaster Recovery

FT and HA improve availability, but neither is a complete data-protection strategy. HA usually restores a VM by restarting it. FT maintains a synchronized secondary for selected host-failure scenarios. Backups provide recovery points, application clustering can provide application-aware service continuity, and disaster recovery addresses broader failures such as site loss.

A resilient design may use HA for broad cluster protection, FT for a small number of especially sensitive VMs, backups for recovery from corruption or deletion, and application-level mechanisms where the service requires independent data or process protection.

Exam-Relevant Notes

FT protects an individual VM with a synchronized primary and secondary.
The secondary runs on a separate ESXi host.
FT differs from HA because FT uses live synchronized takeover, while HA generally restarts the VM.
FT seeks to preserve execution state, including in-memory context, for covered failures.
FT requires capacity for both VM copies and a reliable synchronization network.
Earlier FT implementations supported only single-vCPU VMs; vCPU support expanded in later releases and must be verified for the deployed version.
Snapshot, device, hardware, storage, CPU, licensing, and virtual hardware rules are version-specific.
FT does not correct guest OS failures, application failures, corruption, malware, logical errors, or every storage or site failure.
FT is not a backup or disaster-recovery replacement.

Summary

vSphere Fault Tolerance protects a selected VM by running a synchronized primary and secondary on separate ESXi hosts. When a covered host or primary execution failure occurs, the secondary can become active without the normal VM restart process. This makes FT valuable for critical workloads that cannot tolerate interruption, but it also creates significant capacity, compatibility, networking, licensing, and operational requirements.

Use this FT reference alongside the compatibility guidance for the exact vSphere release in your environment. Validate every requirement before enabling protection, and combine FT with HA, monitoring, backups, application-level recovery, and disaster recovery where appropriate.