VMware ESXi and vSphere Cluster Management
VMware vLockstep and vSphere Fault Tolerance (FT)
Learn how VMware vLockstep synchronizes primary and secondary VMs for vSphere Fault Tolerance, including failover, prerequisites, setup, monitoring, limitations, and troubleshooting.
VMware vLockstep is the synchronization approach used by vSphere Fault Tolerance (FT). FT keeps a protected virtual machine running as a matched pair on separate ESXi hosts. One instance is the active primary VM; the other is the synchronized secondary VM. If the host running the primary fails, the secondary can assume the primary role without requiring the guest operating system or application to restart.
This lesson assumes familiarity with ESXi and vSphere administration, clusters, VMkernel networking, shared storage, HA, and vMotion.
What VMware vLockstep Does
vLockstep keeps the execution of the primary and secondary VM aligned. The secondary follows the primary's execution and relevant events closely enough that it can continue the workload when the primary host becomes unavailable. This is more than copying virtual disks: the goal is synchronized execution state, not merely a second copy of stored data.
FT therefore provides continuous availability for selected workloads. It is intended for services that cannot tolerate the interruption associated with detecting a host failure and restarting a VM. FT does not make every component of an application redundant. Shared storage, DNS, databases, external services, network paths, and clients can still be failure points.
What vLockstep Is Not
- Not general VM replication: replication usually copies disk changes to another location; FT maintains a synchronized running partner.
- Not a backup: FT does not provide historical restore points or protection from accidental deletion, corruption, or ransomware.
- Not a snapshot: snapshots preserve point-in-time disk state and are not a continuous availability mechanism.
- Not vSphere HA: HA normally restarts an affected VM on another host after a host failure. FT uses an already-running secondary.
- Not vMotion: vMotion is planned live migration, not continuous protection from an unplanned host failure.
- Not disaster recovery: FT generally addresses host-level continuity within a vSphere environment, not site loss.
vSphere Fault Tolerance Architecture
The protected VM runs as two coordinated instances. The primary normally executes the guest operating system and application and handles ordinary client traffic. The secondary executes as the partner on a different eligible ESXi host, but it does not independently serve normal client requests while it remains secondary.
The two instances must be placed on different hosts. Otherwise, a failure of their shared host would remove both instances and defeat host-failure protection. Placement awareness, host anti-affinity, sufficient capacity, and reliable network paths are therefore essential.
| Role | Runs application execution | Serves normal client requests | Host location | Role after primary host failure |
|---|---|---|---|---|
| Primary VM | Yes; it is the active instance | Yes | One eligible ESXi host | The failed instance is replaced or restarted according to FT recovery behavior |
| Secondary VM | Yes; it follows the primary in synchronized execution | No, while secondary | A different eligible ESXi host | Promoted to the primary role |
FT Logging Network
The FT logging network is the VMkernel network path used for synchronization traffic between the participating ESXi hosts. It must provide dependable connectivity, suitable bandwidth, consistent VLAN configuration, and an operationally appropriate MTU. Physical uplink redundancy is recommended where the design requires continued connectivity after an adapter or path failure.
Do not treat the FT logging network as ordinary client traffic. Congestion, packet loss, incorrect VLANs, inconsistent MTUs, or a failed uplink can prevent synchronization and leave the VM running with degraded protection.
Failure and Failover Lifecycle
- The primary VM serves the workload while vLockstep keeps the secondary aligned.
- The ESXi host running the primary becomes unavailable.
- vSphere detects the host failure and promotes the synchronized secondary to the primary role.
- Client service continues through the promoted instance. The exact client-visible behavior still depends on network paths, protocols, sessions, and application design.
- vSphere attempts to create or provision a replacement secondary on another suitable host.
- After synchronization completes, the VM returns to the protected state.
Between promotion and successful secondary re-creation, the workload may continue running but has degraded protection. A second host failure during this interval can cause an interruption. Administrators should treat re-protection as an operational priority rather than assuming that failover alone restores full resilience.
FT cannot protect both instances from a failure that affects their common dependency. Examples include a shared datastore outage, a network failure that isolates both hosts, a site-wide power loss, guest-level corruption, or an application failure replicated identically to both instances.
FT Requirements and Prerequisites
FT capabilities and restrictions vary by vSphere release. Before deployment, verify the current VMware compatibility documentation for the exact vCenter Server, ESXi, VM hardware version, guest operating system, maximum vCPU count, supported devices, and configuration maximums. Historical limits should not be reused for a newer release without verification.
| Requirement area | What to validate | Why it matters | Where to verify |
|---|---|---|---|
| Version and licensing | Supported vCenter and ESXi versions, FT entitlement, and edition licensing | FT may be unavailable or restricted without the correct entitlement | vCenter licensing view and release-specific compatibility documentation |
| Management | Hosts are managed by vCenter Server and belong to a compatible cluster | FT configuration, placement, monitoring, and events use vSphere inventory | vSphere Client inventory and cluster configuration |
| CPU and EVC | Compatible host CPUs, virtualization features, and EVC configuration where applicable | CPU incompatibility can prevent pairing or mobility | Host hardware details and EVC configuration |
| VM and guest | Supported guest OS, VM hardware, vCPU count, devices, and features | Some combinations cannot use FT or have release-specific limits | VM compatibility checks and documented support matrix |
| Storage | Candidate hosts can access the required datastores and storage design meets FT requirements | The secondary must be able to use the protected VM's storage | Datastore and host storage views |
| Networking | Consistent VM networks, FT logging VMkernel adapters, VLANs, MTU, routing assumptions, and uplink redundancy | Both client connectivity and synchronization depend on correct networking | Host networking configuration and physical switch documentation |
| Operations | Working DNS, time synchronization, host reachability, and healthy management networks | Identity, event correlation, placement, and reliable control operations depend on them | Host and vCenter health checks |
| Capacity | At least two eligible hosts plus spare CPU, memory, storage, and network capacity | FT consumes resources for both instances and needs room for re-creation | Cluster utilization, reservations, admission control, and DRS |
Compatibility and Feature Limitations
FT is not automatically compatible with every VM configuration. Depending on the vSphere release, virtual devices, passthrough configurations, snapshots, storage modes, encryption choices, and third-party integrations may be unsupported or constrained. Review the exact error shown by the vSphere Client and compare the VM with the release-specific support matrix before changing production settings.
Maintaining a secondary adds CPU, memory, storage, and synchronization-network demand. The protected workload must have manageable resource requirements and enough host headroom to run both instances. Application behavior also matters: FT does not replace application clustering, load balancing, database replication, or redundancy for external dependencies.
Pre-Enable Validation Checklist
- Confirm the vCenter Server and ESXi versions and licensing support FT.
- Confirm that the VM's guest OS, hardware version, vCPU count, virtual devices, storage, and other features are supported.
- Confirm that two or more eligible hosts have compatible CPUs and virtualization features.
- Review EVC and CPU compatibility if the cluster contains different processor generations.
- Confirm that candidate hosts can access the required datastore and VM networks.
- Configure an FT logging VMkernel adapter on each participating host and verify connectivity.
- Check VLAN, MTU, routing assumptions, physical uplinks, and redundancy for the logging path.
- Verify DNS, time synchronization, management reachability, and vCenter health.
- Reserve adequate CPU, memory, and network capacity for both instances and secondary re-creation.
- Review DRS rules, host maintenance status, admission control, and placement constraints.
- Confirm that the workload's interruption objective justifies FT's resource and operational cost.
Enabling and Operating FT
Configure FT Logging
On each participating ESXi host, configure a VMkernel adapter with the FT logging service enabled. Assign addresses and VLAN settings according to the network design. Verify that the interfaces can reach one another using the appropriate ESXi network diagnostic method. Check MTU consistency where jumbo frames are used and confirm that physical uplinks provide the required capacity and redundancy.
For related network preparation, see VLAN configuration and distributed switch concepts.
Enable Fault Tolerance in the vSphere Client
- Open the vSphere Client and locate the compatible VM in the vCenter inventory.
- Review the VM's compatibility checks, storage access, host eligibility, and available cluster capacity.
- Choose the VM action to enable Fault Tolerance.
- Select or confirm the secondary host, or allow cluster policy and placement logic to select an eligible host.
- Submit the operation and monitor the initial secondary creation and synchronization tasks.
- Wait until the VM reports a protected state. Do not consider FT operational merely because the enable operation was submitted.
The exact menu names can vary by vSphere release. Use the current vSphere Client interface and verify release-specific behavior. A related workflow is available at Enable vSphere FT.
Verify and Monitor Protection
Use the VM Summary and Monitor views to identify the primary and secondary placement and current FT state. Use Tasks and Events to follow secondary creation, synchronization, failover, and re-protection. Configure alarms for FT degradation and investigate them promptly; vSphere alarm concepts are covered in alarms in vSphere.
| Observed state | Likely condition | Availability implication | Recommended action |
|---|---|---|---|
| Protected | Primary and secondary are functioning and synchronized | Host-failure continuity is available within the FT design | Continue monitoring and test procedures periodically |
| Degraded protection | Primary runs but a healthy secondary is absent, unsynchronized, or unreachable | Service may continue, but redundancy is reduced | Review events, restore capacity or connectivity, and confirm secondary re-creation |
| Secondary creation or synchronization in progress | Initial enablement or re-protection is underway | Protection is not complete until synchronization finishes | Monitor tasks, resources, storage, and FT logging traffic |
| FT unable to run | Compatibility, licensing, host, storage, or network condition blocks FT | The VM does not have the intended FT protection | Resolve the reported condition and revalidate the configuration |
Maintenance and Routine Administration
For planned maintenance, first identify which host runs the primary and which runs the secondary. Use supported vSphere operations to move or evacuate workloads and preserve two-host separation. Avoid placing both partners on the host being serviced. If FT must be temporarily disabled, understand that the VM loses FT protection until it is enabled again and the secondary completes synchronization.
- Check current FT status and partner placement.
- Confirm that another eligible host has capacity and required storage and networks.
- Use cluster maintenance procedures and supported placement operations.
- Keep at least one suitable host available for the active instance and one for its partner.
- After maintenance, verify host health, FT logging connectivity, partner placement, and the protected state.
See maintenance mode, DRS automation, and DRS anti-affinity rules for supporting operational concepts.
Comparison with Related Technologies
| Technology | Primary purpose | Behavior during host failure | Expected interruption model | Resource overhead | Typical use case |
|---|---|---|---|---|---|
| vLockstep | Synchronize execution of FT partners | Supports secondary promotion | Designed for very low interruption, subject to dependencies | Synchronization and paired-execution overhead | Technical mechanism behind FT |
| vSphere FT | Continuous availability for a selected VM | Secondary takes the primary role | No guest or application restart is intended | Resources for two instances and logging | Small, critical workloads with strict interruption tolerance |
| vSphere HA | Host-failure VM recovery | Restarts the VM on another host | Restart and boot interruption | Cluster spare capacity | Workloads that can tolerate restart |
| vMotion | Planned live migration | Does not automatically protect against an unexpected host failure | Usually minimal during planned migration | Migration network and destination capacity | Maintenance and load balancing |
| Storage replication or site recovery | Protect data and workloads across storage or site failure domains | Recover at a replica location according to the recovery design | Recovery time and data-loss objectives apply | Replica storage, bandwidth, and orchestration | Disaster recovery and site-level failures |
If a workload can tolerate a restart, HA is often simpler and less resource-intensive. Evaluate FT when interruption tolerance is very low, the VM is compatible, capacity is available, and the operational cost is justified. Application clustering or load balancing may be better when multiple application nodes, rolling maintenance, horizontal scale, or independent failure handling are more important than protecting one VM.
Operational Design Guidance
- Choose workloads with strict interruption requirements and manageable CPU, memory, storage, and network demands.
- Use host anti-affinity and placement awareness to keep the partners outside the same host failure domain.
- Keep FT logging paths reliable and separate enough from ordinary traffic to avoid avoidable contention.
- Plan maintenance so the environment does not remain without a secondary longer than necessary.
- Test failover, alarm delivery, event interpretation, client behavior, and secondary re-creation before production reliance.
- Monitor the condition of storage, DNS, time, management networking, application dependencies, and physical infrastructure.
- Combine FT with backups, monitoring, storage protection, application resilience, and disaster recovery.
Failure Domain Coverage and Gaps
| Failure type | Does FT help? | Additional protection needed |
|---|---|---|
| Failure of the ESXi host running the primary | Yes, if the secondary and required dependencies remain available | Verify re-protection and host placement |
| Failure of the ESXi host running the secondary | Usually the primary can continue, but protection becomes degraded | Restore or recreate the secondary promptly |
| Shared datastore or storage system outage | Not necessarily; both instances may depend on the affected storage | Storage resiliency, replication, and backups |
| Network isolation or shared network failure | Only if the required management, client, and logging paths remain available | Redundant switching, uplinks, paths, and network design |
| Site, rack, power, or common infrastructure failure | Only within the failure domain that remains available | Disaster recovery and geographically separate infrastructure |
| Guest, application, or data corruption | No; the behavior may be reproduced by both instances | Backups, application clustering, validation, and recovery procedures |
Practical Examples
Primary ESXi Host Failure
A business-critical VM is protected by FT across Host A and Host B. The primary runs on Host A, while the synchronized secondary runs on Host B. When Host A becomes unavailable, Host B's secondary is promoted to primary. The workload continues from Host B, and vSphere attempts to establish a replacement secondary on Host C. Until that replacement finishes, the VM is running with degraded protection. The administrator should monitor events and confirm that the new partner reaches the protected state.
Planned Host Maintenance
Before placing Host A into maintenance mode, identify the current primary and secondary. Confirm that Host B can continue hosting one partner and that Host C or another eligible host has capacity for the other. Use supported cluster evacuation and placement operations, keep the partners separated, and avoid disabling FT unless necessary. After maintenance, inspect the VM Summary, Tasks, Events, host placement, and FT logging status to confirm protection recovery.
FT Logging Network Issue
Suppose the VM reports reduced FT protection because synchronization traffic cannot reliably cross the designated network. Check that each participating host has a VMkernel adapter with FT logging enabled. Validate IP reachability, VLAN assignment, routing assumptions, MTU consistency where used, physical uplink status, and redundancy. Then review vCenter events and confirm that synchronization resumes and the VM returns to the protected state.
Choosing FT or HA
For a workload that can tolerate a normal restart, HA is generally the simpler recovery approach. For a compatible workload with a very low interruption tolerance, FT may be appropriate if the cluster has spare resources and the organization accepts the added cost and operational complexity. Application clustering may provide better scale or independent application recovery, while site recovery is required for broader failure domains.
Troubleshooting FT
Fault Tolerance Cannot Be Enabled
- Possible causes include an unsupported guest, virtual hardware version, vCPU configuration, device, storage setting, or VM feature.
- The target host may have an incompatible CPU or virtualization configuration.
- The cluster may lack two eligible hosts or sufficient CPU and memory capacity.
- The required licensing entitlement may be missing.
Review the compatibility error in the vSphere Client. Compare the VM and host configuration with the support matrix for the installed release. Redesign or remove an incompatible setting only after assessing its effect on the workload.
Secondary Cannot Be Created or Remains Unprotected
- There may be no eligible target host or insufficient compute resources.
- A candidate host may lack access to the required datastore or VM network.
- The FT logging VMkernel network may be misconfigured or unreachable.
- DRS rules, affinity, maintenance status, or admission control may restrict placement.
Review placement tasks and events, confirm datastore access from candidate hosts, validate FT logging connectivity, and check capacity and cluster constraints.
Protection Becomes Degraded
Determine whether the primary is still running and whether a secondary exists. Review alarms and events for the time and cause of the protection loss. A failed secondary host, logging-network interruption, resource contention, configuration change, or failed secondary re-creation can all produce this state. Restore host eligibility, network connectivity, or capacity, then verify successful re-protection.
Unexpected Performance Impact
Paired execution and synchronization add CPU, memory, and network demand. Measure host utilization and FT logging traffic, check physical NIC capacity and redundancy, and look for congestion or undersized hosts. If the workload does not justify the overhead, consider HA or an application-level availability design instead.
Exam-Relevant Notes
- vLockstep is associated with FT and synchronizes paired VM execution; it is not simply disk replication.
- The primary serves the workload; the secondary is the synchronized standby partner.
- The partners must run on separate ESXi hosts for host-failure protection.
- HA restarts a VM; FT promotes an already-running secondary.
- After failover, the workload may run in a degraded-protection state until a replacement secondary is synchronized.
- FT does not replace backups, disaster recovery, storage resiliency, or application clustering.
- Always use release-specific VMware documentation for compatibility limits, supported devices, and maximums.