VMware ESXi and vSphere Cluster Management

Enable vSphere Fault Tolerance (FT) for a Virtual Machine

Learn how to prepare ESXi hosts, configure FT Logging, enable vSphere Fault Tolerance, verify primary and secondary placement, and troubleshoot common issues.

vSphere Fault Tolerance (FT) protects a virtual machine with a synchronized secondary instance on another ESXi host. If the host running the primary VM fails, the secondary can continue execution with minimal interruption. This lesson describes the core preparation and vSphere Client workflow for enabling FT.

What vSphere Fault Tolerance Does

vSphere Fault Tolerance is an availability feature managed through vCenter Server. It maintains two synchronized instances of a protected VM:

• Primary VM: The active instance that runs the workload and serves normal users and applications.
• Secondary VM: A synchronized standby instance running on a different eligible ESXi host.

FT uses vLockstep to coordinate execution between the primary and secondary. The secondary follows the primary closely enough that, if the primary host fails, vSphere can continue the VM workload from the secondary host.

FT is different from restart-based availability. Features such as vSphere HA generally restart a VM on another host after a host failure. FT instead keeps a secondary instance running in synchronization, so it is designed to reduce the interruption associated with a restart. FT does not replace backups, disaster recovery, or application-level resilience.

Prerequisites and Planning

Plan FT before changing the VM. The protected VM, both hosts, networking, storage, licensing, and cluster capacity must all support the selected FT configuration.

vSphere FT Prerequisites Checklist

Requirement: vCenter-managed cluster. Why it matters: FT configuration and placement are administered centrally. How to verify: Confirm that the ESXi hosts and target VM appear in the vCenter inventory.

Requirement: At least two eligible ESXi hosts. Why it matters: The primary and secondary must run on separate suitable hosts. How to verify: Check host compatibility, licensing, CPU support, and available capacity.

Requirement: FT Logging enabled on VMkernel adapters. Why it matters: FT synchronization traffic needs a host-level network service. How to verify: Inspect VMkernel adapter services on every participating host.

Requirement: Network reachability and bandwidth. Why it matters: Interrupted or congested logging traffic can prevent synchronization. How to verify: Confirm consistent VLAN reachability, low latency, and suitable bandwidth between FT Logging interfaces.

Requirement: VM compatibility. Why it matters: Unsupported guest, virtual hardware, devices, snapshots, or passthrough settings can block FT. How to verify: Review vCenter validation messages and the requirements for the installed vSphere version.

Requirement: Available compute and memory capacity. Why it matters: The cluster must run both VM instances. How to verify: Check CPU, memory, reservations, limits, admission capacity, and resource contention on separate hosts.

Requirement: Storage accessibility. Why it matters: The hosts need access to the VM files and applicable datastores. How to verify: Confirm datastore visibility, permissions, path health, and the storage layout supported by FT.

Requirement: Licensing and version support. Why it matters: FT availability and limits depend on the vSphere edition and version. How to verify: Check assigned licenses and current VMware product documentation.

Host, cluster, and VM requirements

• Manage the cluster through vCenter Server.
• Provide at least two hosts that are compatible enough to run synchronized primary and secondary instances.
• Reserve capacity for both instances, including CPU, memory, reservations, and any cluster admission-control requirements.
• Make sure the VM's guest operating system, virtual hardware version, virtual disks, storage layout, virtual devices, and other settings meet the version-specific FT rules.
• Review unsupported devices and configurations. Passthrough hardware, some virtual devices, snapshots, and particular storage arrangements can prevent FT or require removal before activation.
• Ensure the secondary can access the required datastore or storage resources. A shared or otherwise accessible datastore design may be required for the selected configuration.
• Power off the VM before using the workflow described here.
• Confirm that the license and CPU compatibility requirements are satisfied on every possible host.

FT Logging traffic

FT Logging is a VMkernel-enabled service for Fault Tolerance synchronization traffic. It is not the same as management, vMotion, storage, or virtual-machine traffic.

Use a dedicated network or carefully engineered shared network as appropriate for the environment. A dedicated FT VLAN, consistent reachability on all participating hosts, sufficient bandwidth, and low latency improve predictability. Avoid treating a VMkernel interface as ready merely because the host management network works; the FT Logging interfaces themselves must be able to communicate.

Primary and Secondary VM Roles

Component: Primary VM. Location: One eligible ESXi host. Function: Runs the active workload. What to check: Confirm its host, power state, FT state, and resource availability.

Component: Secondary VM. Location: A different eligible ESXi host. Function: Follows the primary as a synchronized standby. What to check: Confirm its host or secondary location, synchronization state, and resource availability.

Component: FT logging network. Location: VMkernel interfaces on participating hosts. Function: Carries FT synchronization traffic. What to check: Confirm the FT Logging service, VLAN reachability, bandwidth, latency, and path health.

Configure VMkernel Networking for FT Logging

Perform this configuration on every ESXi host that may run either the primary or secondary component. The labels can differ slightly between vSphere Client versions, but the task is to edit a VMkernel adapter and enable the Fault Tolerance Logging service.

1. In the vSphere Client, select an ESXi host in the inventory.
2. Open the host's networking management view.
3. Open the list of VMkernel adapters.
4. Identify the adapter connected to the intended FT network. Check its port group, VLAN, IP configuration, uplinks, and routing design.
5. Edit the VMkernel adapter.
6. Enable the Fault Tolerance Logging service.
7. Save the configuration.
8. Repeat the service configuration and network validation on every eligible cluster host.

Do not assume that enabling the service on one host is sufficient. A primary on one host and a secondary on another need working FT Logging paths in the relevant direction. Keep the VLAN and network policy consistent across the hosts.

vSphere Client workflow:
Host > Configure or Networking > VMkernel adapters
Edit VMkernel adapter > enable Fault Tolerance Logging > Save

Enable Fault Tolerance on the Virtual Machine

1. Cleanly shut down the target VM from the guest operating system or the vSphere Client. Confirm that the VM is powered off.
2. In vCenter, open the VM's actions or context menu.
3. Choose the action to Turn On Fault Tolerance.
4. Read any compatibility, licensing, placement, or configuration warnings presented by vCenter.
5. Resolve blocking issues. Accept confirmation prompts only after reviewing their implications.
6. Wait while vCenter creates and initializes the secondary VM on another eligible host.
7. Allow synchronization to complete before treating the VM as fully protected.

vCenter selects or requests placement for the secondary using eligible hosts, compatibility rules, storage access, and available resources. In a two-host lab, the secondary normally occupies the other suitable host. In a larger cluster, placement can vary as resource and compatibility conditions change.

Verify FT Activation and Placement

After the task completes, open the VM's Summary view. Identify the ESXi host running the primary VM and locate the secondary host or secondary location information. The two components should be on separate eligible hosts.

1. Confirm the VM remains powered on after FT initialization.
2. Review the FT protection state. It should indicate an operational or healthy protected state, not disabled, unavailable, initializing indefinitely, or degraded.
3. Identify the host running the primary VM.
4. Identify the host or location of the secondary VM.
5. Open Recent Tasks and Events to confirm successful secondary creation, synchronization, and placement.
6. Review applicable alarms and monitoring indicators for network, host, storage, or resource problems.

FT status terminology varies by vSphere version. Interpret the displayed state together with recent tasks and events. A status that is initializing may be normal briefly, while a persistent degraded or unavailable state requires investigation.

Operational Behavior and Lifecycle

What happens during a host failure

During normal operation, the primary executes the workload and vLockstep keeps the secondary synchronized. If the primary host fails, vSphere can promote or continue from the secondary role on the surviving host. The goal is continued VM execution rather than waiting for a conventional VM restart.

FT is not an unlimited guarantee. The secondary must remain available, the surviving host must have suitable resources, and the FT communication and storage design must continue to function. If the secondary is lost or cannot be recreated, protection can become degraded even though the primary VM continues to run.

Maintenance and changes

• Before placing a host into maintenance mode, check whether it hosts a primary or secondary FT component.
• Confirm that another compatible host, sufficient capacity, required datastore access, and a working FT Logging network are available.
• Reassess FT after host maintenance, VLAN or uplink changes, storage changes, cluster capacity changes, and licensing changes.
• Changing VM hardware, devices, snapshots, or other settings may require FT to be disabled first or may require a specific sequence in the installed vSphere version.
• Disabling FT, changing VM settings, and performing maintenance can have version-specific sequencing requirements. Follow the prompts and applicable product documentation rather than forcing a change.

Common Limitations and Compatibility Considerations

Do not assume that every powered-off VM can use FT. Validate the complete configuration against the vSphere version in use. Eligibility can be affected by the guest operating system, virtual hardware, CPU compatibility, virtual disks, snapshots, passthrough devices, unsupported virtual devices, storage layout, licensing, host resources, and cluster policies.

Basic FT networking has a narrower meaning than overall FT eligibility. Enabling FT Logging on a VMkernel adapter only provides the communication path for synchronization. It does not make an incompatible VM eligible, provide missing licenses, solve CPU incompatibility, or create storage and capacity that the secondary needs.

Troubleshooting FT

Observed status or symptom: FT cannot be enabled. Likely cause: The VM is powered on, has unsupported hardware or configuration, or the cluster, license, host, or vSphere version does not meet FT requirements. Recommended action: Power off the VM, review validation warnings and VM settings, and confirm version-specific support.

Observed status or symptom: No eligible host for the secondary. Likely cause: Only one suitable host is available, or other hosts fail compatibility, licensing, storage, or network checks. Recommended action: Verify that a separate compatible host is available and that it has FT Logging, datastore access, and capacity.

Observed status or symptom: Secondary creation fails. Likely cause: A storage, resource, placement, compatibility, or host communication problem. Recommended action: Review tasks and events, check datastore access and host health, and inspect CPU and memory capacity.

Observed status or symptom: FT protection is degraded. Likely cause: The secondary is unavailable, the FT Logging network is interrupted, or the secondary cannot be recreated. Recommended action: Review events and alarms, test the FT VMkernel path, and confirm a compatible host with adequate resources.

Observed status or symptom: FT Logging network is unreachable. Likely cause: Incorrect VLAN, port group, IP configuration, uplink, routing, firewall, or VMkernel service selection. Recommended action: Compare the VMkernel configuration on all hosts and verify reachability between the FT interfaces.

Observed status or symptom: Insufficient host resources. Likely cause: The cluster cannot accommodate both VM instances or admission-control policies prevent placement. Recommended action: Check CPU, memory, reservations, limits, contention, datastore capacity, and available host count.

Practical Examples

Two-host application server

A two-host cluster contains compatible ESXi hosts and a shared datastore. Each host has a VMkernel adapter on the same FT Logging network. The administrator powers off an eligible application VM, selects the VM action to turn on FT, waits for vCenter to create the secondary on the other host, and confirms both placements and a healthy protection state in the VM Summary.

Four-host cluster with a dedicated FT VLAN

Each host has a dedicated VMkernel adapter for FT Logging on a common VLAN. The protected VM runs on one host while vCenter creates its secondary on another host with sufficient resources. The administrator checks the VM Summary, Recent Tasks, Events, and alarms to verify successful creation and synchronization.

Host maintenance planning

Before entering maintenance mode, the administrator checks whether the host contains a primary or secondary FT component. The administrator also confirms that another compatible host, accessible storage, sufficient capacity, and a functioning FT Logging network are available so protection can be maintained or re-established.

Exam-Relevant Notes

• FT uses a synchronized primary and secondary VM; HA commonly provides restart-based recovery.
• The secondary must run on a different eligible ESXi host.
• FT Logging is a VMkernel service and is distinct from vMotion, management, storage, and VM traffic.
• Both VM instances consume host resources, so capacity planning matters.
• Power off the VM for the workflow described in this lesson.
• Always verify the post-activation FT state and secondary placement instead of relying only on completion of the configuration task.
• Version-specific compatibility and licensing rules take precedence over generic procedures.

For a repeatable lab procedure, use this vSphere FT enablement guide as the workflow: prepare every host, configure FT Logging, power off the VM, turn on FT through vCenter, and verify the primary, secondary, and protection state.