VMware ESXi and vSphere Cluster Management

VMware vLockstep and vSphere Fault Tolerance (FT)

Learn how VMware vLockstep synchronizes primary and secondary VMs in vSphere Fault Tolerance for rapid, continuous recovery after an ESXi host failure.

VMware vLockstep is the synchronization technology used by vSphere Fault Tolerance (FT). It keeps two copies of a protected virtual machine running with equivalent execution state so that one copy can take over if the ESXi host running the active copy fails.

vLockstep is not a standalone VMware product and is not normally enabled as an independent feature. It is part of the vSphere FT implementation. Administrators enable FT for a supported virtual machine through vCenter Server, and vSphere uses vLockstep to maintain the relationship between the primary and secondary VM.

This article explains the FT architecture, synchronization concept, failover sequence, planning requirements, activation workflow, monitoring considerations, and differences from other availability technologies.

What Is vSphere Fault Tolerance?

vSphere Fault Tolerance is a vSphere availability capability that maintains a live secondary copy of a protected virtual machine on another ESXi host. The goal is to keep the workload available if the primary VM or its host fails.

When FT operates as intended, the application can continue without an application-visible restart, and synchronized in-memory execution state is preserved at failover. These outcomes are commonly described as zero downtime and zero data loss for the protected execution state. They describe the intended behavior for a suitable failure scenario, not a guarantee against every application, storage, network, or site failure.

FT protects a selected VM. It does not automatically protect every VM on an ESXi host, and it does not make the entire host fault tolerant. Each workload that needs FT protection must meet the feature's compatibility and capacity requirements.

Primary and Secondary VM Roles

The protected workload has two VM copies: a primary VM and a secondary VM. Both represent the same workload rather than two independently managed application servers.

Characteristic	Primary VM	Secondary VM
Active workload processing	Executes the active workload.	Executes synchronized work so it can take over.
Client request handling	Receives network requests and returns responses.	Does not independently serve the workload while the primary is healthy.
Execution-state synchronization	Produces execution changes that are mirrored to the secondary.	Applies the synchronized execution changes.
Host placement	Runs on one eligible ESXi host.	Runs on a different eligible ESXi host.
Role after primary-host failure	Stops being the active copy if its host fails.	Is promoted to the primary role.

The primary is the active copy. It receives client traffic, runs the guest operating system and applications, and generates the execution activity that must be reflected on the secondary.

The secondary is a live synchronized counterpart. It is not a second application server intended to process independent requests. While the primary is healthy, the secondary exists to be ready for promotion.

How vLockstep Synchronization Works

A virtual machine's state includes much more than files on a datastore. Its state includes processor execution, memory contents, device activity, and other runtime changes. A copy of the virtual disks alone would not contain the complete point-in-time state needed to continue an application immediately.

vLockstep mirrors the primary VM's execution to the secondary VM. Conceptually, the primary performs an operation, and the corresponding execution is delivered to the secondary so that both copies maintain equivalent runtime state. The synchronization path uses the configured FT logging network between participating ESXi hosts.

This design means the secondary is already running the guest workload state when a failure occurs. It does not need to boot the guest operating system and restart the application as part of normal FT takeover. The exact implementation details and supported behavior depend on the vSphere release, but the central idea is synchronized execution rather than periodic disk copying.

Primary Host Failure and Failover

Consider a business application protected by FT. Its primary VM runs on ESXi Host A, and its synchronized secondary runs on ESXi Host B.

During normal operation, the primary on Host A serves the application, while the secondary on Host B follows its execution through vLockstep.
Host A fails unexpectedly.
vSphere detects that the primary is unavailable.
The secondary on Host B is promoted to the primary role and begins serving the workload.
vSphere attempts to create a replacement secondary VM on another eligible ESXi host.
After the replacement is synchronized, the VM again has a primary and secondary pair.

Stage	Primary VM State	Secondary VM State	Administrator or vSphere Action
Normal protected operation	Active and serving requests.	Running in synchronized standby operation.	Monitor both roles and FT health.
Primary host failure detected	Unavailable because its host failed.	Still available on the separate host.	vSphere detects the failure and initiates role transition.
Secondary promotion	Former primary remains unavailable.	Becomes the active primary and serves the workload.	Verify service and FT status.
Replacement secondary creation	Former secondary is now the primary.	A new copy is created on another suitable host.	vSphere places and synchronizes the replacement.
Redundancy restored	Active on the surviving host.	Healthy replacement secondary is synchronized.	Continue monitoring placement, resources, and logging.

After promotion, the VM may remain available while the new secondary is being built. During that interval, the workload can be running successfully but temporarily lacks full FT redundancy. A second failure during rebuilding may therefore have a different outcome than a failure during healthy two-copy operation.

Why the Hosts Must Be Separate

Primary and secondary copies must run on separate ESXi hosts to protect against an individual host failure. If both copies were placed on the same host, a failure of that host could remove both copies at once.

Separate placement gives the copies independent host execution environments. It does not protect against every shared dependency: a common storage failure, a site outage, a network design failure, or an application-level fault may still affect both copies.

A replacement secondary also requires another eligible host with sufficient CPU, memory, network, and storage access. If the cluster has only two hosts and one fails, vSphere may be unable to restore the secondary until another suitable host becomes available.

FT Prerequisites and Planning Requirements

Before enabling FT, validate the complete deployment against the support rules for the installed vSphere release. FT compatibility and scale limits can change between releases, so current VMware documentation and the release-specific compatibility information should be treated as authoritative.

Requirement Area	What to Validate	Why It Matters
Eligible ESXi hosts	Hosts are managed appropriately by vCenter Server, belong to a suitable cluster or available inventory structure, and meet FT eligibility rules.	FT needs a supported location for both VM copies and for later secondary rebuilding.
Host resource capacity	Multiple hosts have CPU, memory, network, and storage headroom for two running copies of the protected workload.	The secondary is a live VM copy, not merely an inactive file.
Shared storage	Candidate hosts can access the required shared datastores and VM files.	Storage access supports placement and operation of the protected VM copies.
FT logging network	Participating ESXi hosts have reliable, adequately sized connectivity for FT logging and synchronization.	Synchronization depends on communication between the primary and secondary hosts.
VM and guest compatibility	The VM configuration, virtual hardware, guest operating system, and related features are supported by the installed release.	Unsupported configurations may prevent FT activation or produce operational limitations.
Current version-specific support limits	Check the current release documentation for supported VM characteristics, host requirements, and FT scale limits.	Exact limits and supported combinations are release-dependent.

vCenter Server, Clusters, and Hosts

vCenter Server provides the management plane used to configure and monitor FT. The ESXi hosts provide the compute environments where the primary and secondary run. A vSphere cluster commonly supplies the eligible host pool and resource-management context, although the exact inventory and cluster requirements depend on the vSphere release and design.

FT is not simply a property of one VM in isolation. The VM, its hosts, storage, network paths, vCenter configuration, and available capacity must work together. A VM can be compatible in principle but still fail activation if no suitable secondary host or network path is available.

Enabling FT at a High Level

Validate compatibility. Confirm that the VM, guest operating system, virtual hardware, and configuration are supported in the installed vSphere version.
Prepare eligible hosts. Confirm at least two suitable ESXi hosts and enough CPU, memory, storage, and network capacity for both copies.
Verify storage. Ensure candidate hosts can access the required shared storage.
Configure FT logging. Provide an appropriate FT logging network between participating ESXi hosts and verify reachability.
Enable protection. In vCenter Server, select the VM and use the Fault Tolerance action.
Allow secondary creation. vSphere creates and places the secondary VM on another eligible host.
Verify health. Confirm that the primary and secondary statuses report healthy protection and that synchronization has completed.
Monitor continuously. Check that host placement, FT logging, resource headroom, and secondary health remain suitable.

Preparation: compatibility -> hosts and capacity -> storage -> FT logging network
Activation: select VM in vCenter Server -> Fault Tolerance -> enable
Validation: primary healthy + secondary healthy + synchronization complete

FT should not be treated as a substitute for application backups, disaster recovery, or capacity planning. It is an availability mechanism for a protected VM, not a complete data-protection strategy.

Monitoring and Operational Awareness

Administrators should distinguish the following operational conditions:

Protected and healthy: The primary is serving the workload and a synchronized secondary is available.
Primary active: The current primary is the copy handling client requests and application execution.
Secondary active: The former secondary has been promoted after a primary failure.
Failover occurred: A role transition has taken place and should be investigated even if the workload remains available.
Secondary rebuilding: A replacement secondary is being created or synchronized, so redundancy may be temporarily reduced.

Monitor the availability of participating ESXi hosts, FT logging connectivity, CPU and memory headroom, storage access and performance, and placement of the secondary VM. A healthy primary does not by itself prove that the VM is fully protected; the secondary must also be present and synchronized.

FT Compared with Other Availability Technologies

Capability	Typical Recovery Behavior	Runtime State Preservation	Primary Use Case
vSphere Fault Tolerance	A synchronized secondary takes over when the primary or its host fails.	Designed to preserve synchronized live execution state and avoid an application-visible restart.	Continuous availability for selected critical VMs.
vSphere High Availability	Affected VMs are restarted on another host after a host failure.	Does not provide the same continuously running synchronized secondary model.	Cluster-level VM restart-based recovery.
Backup	Data and VM state are restored from a recovery point.	Recovery point objectives determine how much recent work may need to be recreated.	Recoverability from corruption, deletion, or broader data-loss events.
Replication or disaster recovery	A replica is activated at a planned or recovery location.	Usually reflects a replication point rather than synchronized live execution.	Site-level or infrastructure-level recovery.

HA and FT solve different operational problems. HA generally recovers by restarting the VM, which can cause boot and application restart time. FT uses an already running synchronized secondary for rapid takeover.

Backups and replication remain important because FT does not replace historical recovery points, protection from accidental deletion or corruption, or recovery across sites. FT primarily addresses failure of the primary VM or its ESXi host within the designed vSphere environment. Broader disaster recovery may require protection in another site or failure domain.

Practical Failure Scenarios

Primary ESXi Host Failure

A business application VM is protected by FT. The primary runs on ESXi Host A, and the synchronized secondary runs on ESXi Host B. Host A fails. The secondary on Host B becomes the active primary without waiting for a normal VM reboot. vSphere then attempts to create a new secondary on a suitable third host, restoring the protected pair.

Teaching point: FT maintains service continuity by promoting an already synchronized VM copy.

Why Separate Hosts Matter

Placing both copies on one ESXi host would expose both to the same host outage. Placing them on different hosts allows one copy to survive the failure of the other host.

Teaching point: Redundancy protects against a host failure only when the redundant copies have independent host placement.

FT Versus HA Outcome

With HA, a VM may need to restart on another host after the original host fails. With FT, the existing synchronized secondary assumes the active role.

Teaching point: FT is designed for continuous operation, while HA provides restart-based recovery.

Troubleshooting FT

FT Cannot Be Enabled

Possible causes:

The VM, guest operating system, virtual hardware, or configuration is unsupported by the installed vSphere release.
No eligible secondary host is available.
Required storage or FT logging connectivity is unavailable.
There are insufficient host resources for the secondary copy.

Checks:

Review FT compatibility validation messages in vCenter Server.
Check host eligibility, cluster membership, and available capacity.
Confirm datastore access from candidate hosts.
Validate FT logging network configuration and reachability.

The VM Runs but Is Not Fully Protected After Failover

Possible causes:

The former secondary has been promoted, but a replacement secondary has not been created.
No suitable host or sufficient capacity exists for the new secondary.
Network or storage conditions prevent secondary creation.

Checks:

Inspect FT status to determine whether the VM has a healthy secondary.
Check available hosts, resource utilization, storage access, and FT logging health.
Resolve placement or connectivity constraints and confirm that vSphere can rebuild redundancy.

Secondary Creation or Synchronization Is Slow

Possible causes:

Insufficient FT logging bandwidth or excessive latency.
Network misconfiguration between ESXi hosts.
Host resource pressure or storage performance constraints.

Checks:

Verify the FT logging path and configuration on all relevant hosts.
Review network performance and error indicators.
Check CPU, memory, and storage contention before protecting additional VMs.

Exam-Ready Summary

vLockstep is the synchronization mechanism used by vSphere FT; it is not a separate standalone product.
FT maintains a live primary and secondary VM for rapid takeover after a primary or host failure.
The primary serves client requests and performs active workload execution.
The secondary follows the primary's execution and does not independently serve the workload while the primary is healthy.
Primary and secondary copies must run on separate ESXi hosts.
After failover, the former secondary becomes primary, and vSphere attempts to create a replacement secondary.
FT depends on supported versions and VM configuration, eligible hosts, shared storage, capacity, and an FT logging network.
HA normally restarts a VM; FT promotes a synchronized running copy.
FT improves availability but does not replace backups, replication, disaster recovery, or capacity planning.

For a concise reference to this subject, see VMware vLockstep and vSphere Fault Tolerance.