VMware ESXi and vSphere Cluster Management
vSphere Fault Tolerance (FT) Explained
Learn how VMware vSphere Fault Tolerance maintains a synchronized secondary VM, how it differs from HA, its requirements, limitations, resource impact, and failover behavior.
vSphere Fault Tolerance (FT) is a vSphere availability feature that keeps a protected virtual machine running through certain ESXi host or VM execution failures. FT runs an active primary VM and a synchronized secondary VM on different ESXi hosts.
The secondary continuously follows the primary's execution state. If the primary host or qualifying primary VM failure occurs, vSphere promotes the secondary to active service. The goal is continued availability without the recovery delay associated with restarting a VM and without losing synchronized in-memory execution state.
What vSphere Fault Tolerance Means
In normal operation, the primary VM serves users and applications. The secondary VM is a running standby execution instance on another compatible ESXi host. Both VMs belong to the same vSphere environment and are managed through vCenter Server communication.
FT uses lockstep execution: the secondary follows the primary's execution in a coordinated manner. Execution-state information is transmitted over the FT logging network, a VMkernel networking path designed for communication between the two instances.
This design targets a demanding availability objective. A protected host failure should not require a conventional VM restart, and synchronized memory and processor execution state can continue from the secondary. “Zero downtime” describes the recovery objective for a qualifying protected failure; client connections and application behavior still require testing.
How FT Works
Primary and secondary roles
- Primary VM: the active instance that normally executes the workload and serves traffic.
- Secondary VM: the synchronized instance that follows the primary and can assume active service.
- Separate hosts: the two instances must be placed on different eligible ESXi hosts so one host failure does not remove both copies.
- FT logging: the network traffic that carries execution-state information from the primary toward the secondary.
The initial enablement process creates the secondary and synchronizes it with the primary. During steady state, vSphere monitors the relationship and the health of the hosts, storage, and logging path.
Automatic failover
- The primary ESXi host or primary VM experiences a qualifying failure.
- The secondary is promoted to the active primary role.
- The workload continues from the synchronized execution state.
- When cluster capacity, storage, networking, and compatibility requirements permit, vSphere creates and synchronizes a replacement secondary on another eligible host.
Protection is temporarily degraded between promotion and successful creation of a replacement secondary. The application may still be running, but it no longer has the same redundant execution instance.
FT Compared with vSphere HA
vSphere High Availability (HA) and FT both address host-level availability, but they use different recovery methods. HA detects a host failure and restarts affected VMs on another host. FT already has a synchronized VM executing on another host.
| Characteristic | vSphere Fault Tolerance | vSphere High Availability |
|---|---|---|
| Protection method | Maintains a synchronized, running secondary VM. | Detects a host failure and restarts the affected VM. |
| Behavior after host failure | Promotes the secondary to active service. | Registers and starts the VM on an available host. |
| Expected interruption | Designed for immediate continuation after a qualifying failure; validate application and client behavior. | Includes detection, placement, boot, and guest-service startup time. |
| Memory and execution-state preservation | Preserves synchronized in-memory execution state for the protected failure scenario. | May lose in-flight memory state when the VM is restarted. |
| Resource overhead | Requires resources for both primary and secondary instances plus logging traffic. | Usually requires capacity to restart workloads after a failure. |
| Best-fit workloads | Extremely critical, interruption-intolerant workloads that fit FT limits. | Workloads that can tolerate restart-based recovery. |
| Application and guest OS failure protection | Does not create an independent healthy application or guest OS; identical failures can affect both instances. | Also does not solve application or guest OS defects. |
FT is therefore not simply “HA with a faster restart.” HA generally offers a restart-oriented RTO, while FT targets near-continuous availability for qualifying host failures. RPO describes the amount of data loss that is acceptable; synchronized FT execution can preserve execution state, but it does not protect against logical corruption.
When to Use FT
Consider FT for workloads where even a short host-failure interruption has significant operational, financial, or safety consequences. Examples include a critical transaction-processing service, a control-related workload, or a legacy line-of-business application that cannot provide its own clustering or redundancy.
A legacy single-instance application can be a strong candidate when application-level clustering is unavailable. Before enabling FT, verify that its VM configuration, guest operating system, storage, hosts, licensing, and network design meet the requirements for the installed release.
Apply FT selectively rather than to every VM. Each protected workload consumes resources twice, increases network activity, and reduces consolidation flexibility. Use HA for workloads that can tolerate restart-based recovery, and reserve FT capacity for workloads whose recovery objectives justify the additional cost.
Protection Scope and Limitations
| Failure or event | FT outcome | Additional control needed |
|---|---|---|
| ESXi host failure | Secondary can be promoted when the failure qualifies and FT is healthy. | Capacity planning, monitoring, and a procedure to restore the replacement secondary. |
| Primary VM execution failure | May trigger secondary promotion for supported execution failures. | Root-cause investigation and guest or application remediation. |
| Guest OS crash | The same guest state and defect can affect both VM instances. | OS hardening, patching, monitoring, and recovery procedures. |
| Application crash | The application can fail on both synchronized instances. | Application monitoring, clustering, restart policy, or vendor resilience. |
| Data corruption | Corrupt writes can be reproduced or shared by both instances. | Backups, integrity controls, and point-in-time recovery. |
| Accidental deletion or malicious action | FT does not provide an independent recovery copy. | Access controls, security controls, backups, and incident response. |
| Storage outage | Outcome depends on the storage design and failure type; FT is not a universal storage-redundancy mechanism. | Supported redundant storage and storage-specific recovery design. |
| Site disaster | Both instances may be lost if they share the affected site. | Site-level disaster recovery, replication, and documented recovery plans. |
FT protects execution availability, not the correctness of the workload. An operating-system defect, application bug, configuration error, database corruption, or malicious command can be executed by both copies. Combine FT with vSphere alarms and monitoring, backups, application resilience, and security controls.
Resource and Operational Impact
An FT-protected VM requires capacity for both instances. A VM configured with 2 GB of memory needs memory capacity for the active and secondary instances, in addition to ESXi and cluster overhead. CPU demand is also duplicated according to the workload and FT implementation.
- CPU and memory: reserve enough resources for primary and secondary execution.
- Storage: provide access to the VM's disks and the secondary's required files through shared or otherwise supported storage.
- Network: size the FT logging path for the workload's execution-state traffic, with adequate bandwidth and low latency.
- Placement: keep primary and secondary instances on separate hosts and retain eligible spare hosts.
- Consolidation: account for the second instance when calculating host density and capacity ratios.
- Admission control: use an appropriate admission-control policy so the cluster reserves capacity for failures and replacement secondaries.
Do not treat the secondary as free standby capacity. A design that is full during normal operation may be unable to recreate protection after a host failure. Test capacity under the expected failure scenario, not only under normal load.
Compatibility and Prerequisites
| Requirement area | What to verify | Why it matters |
|---|---|---|
| vCenter and cluster configuration | Hosts are managed by vCenter Server and participate in an appropriate, healthy cluster. | FT configuration and placement are coordinated centrally. |
| ESXi host compatibility | CPU, ESXi release, hardware, and configuration are compatible across eligible hosts. | The secondary must be able to execute consistently on its host. |
| Licensing | The installed vSphere edition includes the required FT entitlement. | Feature availability varies by edition and release. |
| Shared or supported storage | Both hosts can access storage in a supported configuration. | The primary and secondary require consistent access to VM data. |
| FT logging network | Dedicated or appropriately designed VMkernel connectivity with sufficient bandwidth, low latency, and redundancy. | Execution-state replication must remain current and reliable. |
| Host resource headroom | CPU, memory, storage, and placement capacity remain available after a host failure. | vSphere must keep the workload running and recreate a secondary. |
| VM hardware and devices | Virtual hardware, disks, devices, guest configuration, and networking are supported. | Some devices and operations are incompatible with FT. |
| Supported vCPU count | Confirm the limit for the exact vCenter and ESXi release. | FT vCPU capabilities vary by version, edition, hardware, and configuration. |
| Snapshots and operations | Verify snapshot behavior and support for the installed release and intended workflow. | Snapshot and maintenance behavior is not universal across releases. |
Compatibility limits can include supported vCPU counts, virtual hardware, guest operating systems, CPU generations, storage modes, networking, and device configurations. Older FT implementations supported only single-vCPU protected VMs; that historical limit must not be assumed for current releases. Modern releases may support more vCPUs, but the exact limit remains version-specific.
Before design or implementation, check the VMware compatibility guide and the FT documentation matching the exact vCenter Server and ESXi versions. A compatibility check is more reliable than assuming that a configuration supported by one release is supported by another.
VM Configuration Restrictions
Some VM features, virtual devices, storage modes, passthrough devices, guest configurations, and administrative operations are incompatible with FT or require special handling. Unsupported passthrough devices and certain virtual hardware configurations are common reasons an enablement task fails.
Snapshot behavior also depends on the vSphere release and workflow. Do not assume that every snapshot operation is universally supported while FT is enabled. Verify the release-specific rules before creating, reverting, consolidating, or otherwise managing snapshots. See snapshot consolidation guidance when investigating snapshot state.
Run the vSphere compatibility checks before enabling FT. Review task errors, VM compatibility status, device settings, disk modes, guest configuration, and the release-specific documentation rather than removing configuration features blindly.
Enabling and Managing FT
High-level workflow
- Confirm the FT entitlement, cluster health, eligible hosts, datastore access, and available CPU and memory headroom.
- Create or identify the VMkernel network path for FT logging on each eligible ESXi host. Use redundant physical uplinks where the design requires it, and validate bandwidth, latency, and connectivity.
- Check the target VM's hardware, guest, disk, snapshot, and device compatibility.
- In the vSphere Client, select the VM and use its availability or Fault Tolerance action to enable FT.
- Choose secondary placement when the workflow permits, or allow vSphere to place it on an eligible host.
- Monitor secondary creation and the initial synchronization process.
- Confirm that the VM reports a protected, healthy FT state before relying on it.
- Configure alerts for degraded protection, unavailable secondary instances, logging problems, host capacity, and related failures.
After enablement, understand which instance is primary and which is secondary, but avoid manual actions that split, power off, move, or otherwise disrupt the protected relationship. Use supported vSphere operations and follow the maintenance behavior documented for the installed release.
Disable FT when maintenance, troubleshooting, or an unsupported VM change requires it. Plan the change so the workload has an acceptable availability posture while protection is disabled, and revalidate synchronization after re-enabling FT.
Failure Behavior and Recovery
Primary host failure
When the host running the primary fails, the secondary continues as the active primary. vSphere then attempts to create a replacement secondary on an eligible host. During this process, monitor whether protection returns to a healthy state.
Primary VM execution failure
A qualifying execution failure can cause the secondary to be promoted. The promotion addresses service continuity for that failure type, but it does not explain why the original VM failed. Investigate ESXi, guest, application, storage, and network evidence after service is stable.
Degraded protection
If no eligible host has enough CPU, memory, storage, or network capability for a replacement secondary, the active VM may remain online while FT protection is degraded. Restore host health, add or free capacity, verify datastore access, and correct FT logging connectivity.
Planned maintenance
Before entering a host into maintenance mode, confirm that FT protection is healthy and understand how migration, placement, and maintenance operations behave in the installed version. Ensure another eligible host is available so both the active VM and its secondary can remain protected.
Practical Examples
Legacy line-of-business application
A single-VM application cannot be clustered at the application layer and must remain available during an ESXi host failure. The administrator evaluates FT only after checking the VM configuration, host compatibility, licensing, shared or supported storage, capacity, and FT logging network.
Choosing FT or HA
A departmental file-processing VM can tolerate several minutes of restart time, so HA is likely sufficient. A small transaction-processing VM cannot tolerate a host-failure interruption, so FT is considered if the workload fits the current FT limits and the cluster can afford the duplicated resources.
Guest OS failure
If the guest operating system experiences a kernel panic caused by an OS defect, FT does not provide an independent healthy OS. Both instances follow the same guest execution. OS maintenance, monitoring, backups, and application-level resilience are still required.
Capacity planning
A protected VM with 2 GB of memory requires capacity for both the active and secondary instances, plus ESXi and cluster overhead. The design must verify that a host failure will not prevent the remaining workload from running or prevent vSphere from creating a replacement secondary.
Troubleshooting FT
FT cannot be enabled
- Check for an unsupported vCPU count, virtual hardware version, guest configuration, disk mode, virtual device, or passthrough device.
- Confirm that the vSphere edition provides the required FT entitlement.
- Verify that an eligible host has sufficient CPU, memory, storage, and placement capacity.
- Check the FT logging VMkernel network for correct configuration and host-to-host connectivity.
- Review snapshot and other VM state for compatibility with the deployed release.
- Read the vSphere task error and compare the configuration with the release-specific FT compatibility documentation.
FT is degraded or the secondary is unavailable
- Determine whether a host failure or maintenance action removed the secondary.
- Check capacity for a replacement secondary, including CPU, memory, storage, and placement constraints.
- Verify datastore access and host compatibility.
- Measure the FT logging path for interruption, packet loss, congestion, or insufficient performance.
Application remains unavailable after failover
Check the guest OS, application, database, DNS, network, and external dependencies. Clients or application components may require reconnection. FT failover is not a complete resolution for an application defect, logical corruption, or an unavailable dependency.
High network utilization or synchronization concerns
Measure FT logging traffic and compare it with the network design. Investigate congestion, packet loss, failed uplinks, inconsistent VMkernel configuration, and competing traffic. Isolate or prioritize traffic where appropriate, and size bandwidth using measured workload behavior and vendor guidance.
Design Checklist
- Define the workload's RTO and RPO, including what “continuous availability” means to the application owner.
- Confirm that FT, HA, application clustering, backups, and site recovery address different failure domains.
- Verify the exact vCenter Server and ESXi release, edition, CPU compatibility, guest, device, storage, networking, and vCPU limits.
- Reserve capacity for both FT instances and for replacement-secondary creation after a host failure.
- Provide a reliable, sufficiently sized, and appropriately redundant FT logging network.
- Use alarms and operational runbooks to detect degraded protection and investigate failovers.
- Test controlled failover and application behavior before production reliance.
- Document how to disable FT for maintenance, troubleshoot the VM, and restore healthy protection.
Related vSphere Skills
FT depends on several foundational administration skills. Review cluster creation, admission-control policy, vSphere HA, DRS automation levels, and distributed switches before implementing it in a production cluster.