VMware ESXi and vSphere Cluster Management

vSphere Fault Tolerance Requirements and Limitations

Learn the legacy vSphere Fault Tolerance requirements for clusters, ESXi hosts, networking, shared storage, and eligible virtual machines.

vSphere Fault Tolerance (FT) is a vSphere availability feature that runs a synchronized secondary copy of a protected virtual machine (VM). The active instance is the primary VM; the synchronized standby instance is the secondary VM. If the host running the primary fails, FT can continue the workload on the secondary without the VM restart associated with a typical host-failure recovery.

Legacy FT uses vLockstep to keep primary and secondary VM execution synchronized. FT is different from vSphere HA: HA restarts a VM on another host after a failure, whereas FT is designed to avoid an interruption caused by a host failure for supported workloads. HA must still be enabled for the cluster.

Requirements at a glance

FT eligibility is not determined by the VM alone. Requirements must be satisfied across the cluster, participating ESXi hosts, host networking, shared storage, and the individual VM configuration.

Cluster-level requirements

• The cluster must contain at least two ESXi hosts certified for FT.
• Participating hosts must use the same supported FT version or a matching host build level.
• All applicable hosts must be able to access the required shared datastores.
• Hosts must have common network access for the VM networks used by the workload and for FT operations.
• FT logging networking and vMotion networking must both be configured.
• vSphere HA must be enabled on the cluster. See Enable vSphere HA for the related cluster configuration.
• Host certificate checking must be enabled in vCenter Server settings. It is enabled by default in vCenter Server 4.1 and later, but should still be verified.

These conditions allow vCenter Server to trust the participating hosts and place the primary and secondary instances on hosts that can communicate, access storage, and run the same supported FT implementation.

ESXi host requirements

Processor and firmware compatibility

Each host must use a CPU belonging to an FT-compatible processor group. This is a CPU compatibility grouping that permits the protected workload to execute consistently on both hosts. CPU differences can prevent secondary placement or cause an FT compatibility check to fail.

Hardware virtualization (HV) is CPU virtualization support provided by the host firmware. HV must be enabled in the BIOS of every participating ESXi host. A host can have a suitable processor but remain ineligible if this firmware setting is disabled.

Certification, software, and licensing

• Verify that each host is listed as FT-certified in the VMware Hardware Compatibility List (HCL), the reference used to validate supported server hardware.
• Verify compatible processor grouping and matching supported ESXi or FT host version and build requirements.
• Apply the required Fault Tolerance license to each participating host.

Certification, CPU compatibility, and consistent host software levels matter because the primary and secondary VMs may run on different hosts. Shared storage alone does not make a host pair eligible.

Networking prerequisites

The FT logging network is the host network path that carries synchronization traffic between the primary and secondary VMs. It must be configured on every participating host and planned for reliable, sufficiently provisioned connectivity. Avoid assuming that an arbitrary network path is suitable; use a supported, properly configured host networking design for the installed release.

The vMotion network is the configured host network used for vMotion operations. It is a separate required host capability for this FT configuration. Configure it on every participating host.

• Verify FT logging on each host.
• Verify vMotion networking on each host.
• Ensure hosts can reach the same relevant VM networks.
• Plan FT logging capacity and reliability so synchronization traffic does not contend with an undersized or unstable path.

Shared storage requirements

All VM files must reside on shared storage accessible by every ESXi host that may participate in FT. Supported shared-storage protocols for the described legacy feature set are:

• Fibre Channel (FC)
• Fibre Channel over Ethernet (FCoE)
• iSCSI
• Network File System (NFS)

Shared datastore access lets either host open the VM configuration and virtual-disk files. Confirm datastore visibility from each host rather than checking only the host currently running the primary VM. Related storage subjects include configuring an NFS datastore, creating a VMFS datastore, and Raw Device Mapping.

Virtual machine eligibility requirements

A legacy FT-protected VM must meet all of the following conditions:

• It has exactly one virtual CPU.
• It runs a supported guest operating system.
• Its configuration and disk files are on shared storage available to all participating hosts.
• Its virtual disks use thick-provisioned VMDKs or virtual-mode RDMs.
• It does not use a physical-mode RDM. An RDM is a VM disk mapping type; virtual compatibility mode is supported here, while physical compatibility mode is not.
• It has no snapshots when FT is enabled. A snapshot is a point-in-time VM state.
• It is not a linked clone. A linked clone depends on another VM's disks and is not eligible for FT.
• Its configuration contains no USB devices, sound devices, serial ports, or parallel ports.
• No VMDK is larger than 2 TB.

Pre-enable validation checklist

Practical eligibility examples

Eligible legacy FT workload

Consider a cluster with two FT-certified ESXi hosts using compatible CPUs and the same required build level. HA, FT logging, and vMotion are configured. A supported single-vCPU VM is stored on a shared NFS datastore. Its disks are thick provisioned, it has no snapshots, and it has no prohibited virtual devices. Because the cluster, hosts, networks, storage, and VM all satisfy the checks, this is an eligible design subject to release-specific validation.

Disk configuration rejects an otherwise suitable VM

A VM can pass cluster and host checks and still fail FT validation if it uses a physical-mode RDM or contains a VMDK larger than 2 TB. These are independent disk eligibility failures; correcting network or CPU settings will not remove them.

Attached devices or VM state require cleanup

A snapshot, USB device, sound device, serial port, or parallel port can make the VM ineligible. Remove the unsupported configuration, and handle snapshots according to your operational policy before attempting to enable FT again. A linked clone also cannot be converted into an eligible FT workload merely by changing its power state.

Shared storage is not enough

Two hosts may see the same datastore but still be unable to support FT if they are not FT-certified, do not use a compatible processor group, have different required builds, or have hardware virtualization disabled in firmware. Check every host prerequisite.

Troubleshooting FT enablement failures

FT cannot be enabled for a VM with healthy hosts

• Confirm that the VM has only one virtual CPU.
• Check for snapshots and linked-clone status.
• Inspect virtual hardware for USB, sound, serial, and parallel devices.
• Verify guest operating-system support.
• Verify disk provisioning, RDM compatibility mode, and VMDK size.

The secondary VM cannot be placed or started on another host

• Verify that both hosts are FT-certified and in a compatible processor group.
• Verify the required matching host version or build level.
• Verify that BIOS hardware virtualization is enabled.
• Verify licensing on every participating host.
• Verify common datastore and relevant network access from all hosts.

The error identifies a network prerequisite

• Verify FT logging on each host.
• Verify vMotion networking on each host.
• Verify common network availability between participating hosts and access to the VM networks.

The cluster does not meet FT prerequisites

• Confirm that vSphere HA is enabled.
• Confirm that at least two eligible FT hosts are present.
• Confirm that host certificate checking is enabled in vCenter Server.

Implementation planning and exam notes

When FT enablement fails, investigate by scope: cluster first, then host compatibility and licensing, networking, storage, and finally VM hardware and state. Do not assume that the VM is the only cause.

1. Identify at least two candidate FT hosts.
2. Validate certification, CPU grouping, firmware virtualization, software level, and licensing.
3. Validate HA, certificate checking, FT logging, vMotion, common VM networks, and shared datastore access.
4. Prepare the VM by checking guest OS, one-vCPU configuration, disk backing, disk size, snapshots, clone type, and prohibited devices.
5. Recheck the installed vSphere release before enabling FT because legacy limitations may differ from newer FT implementations.

For adjacent administration tasks, see Enable vSphere FT, CPU compatibility for vMotion, creating clusters, and editing virtual machine settings.