VMware ESXi and vSphere Cluster Management
vSphere Fault Tolerance Requirements and Limitations
Learn the cluster, ESXi host, networking, shared storage, licensing, and VM requirements for validating vSphere Fault Tolerance readiness.
vSphere Fault Tolerance (FT) is a VMware availability capability that runs a protected virtual machine with a synchronized secondary copy. The primary VM services the workload during normal operation, while the secondary VM runs on another ESXi host and is ready to continue execution if the primary host fails.
FT is designed for rapid continuity rather than a post-failure restart. The historical VMware mechanism associated with synchronizing the two copies is vLockstep. It keeps execution of the primary and secondary VM coordinated so the secondary can take over with minimal interruption.
Version and compatibility scope
FT requirements vary substantially between vSphere releases. Licensing editions, ESXi versions and builds, processor compatibility, VM hardware versions, guest operating systems, disk limits, and supported virtual devices can all change the result. A configuration that was eligible for an earlier FT implementation may not represent the limits of a current release.
The frequently cited one-vCPU restriction belongs to the historical FT implementation. It must not be treated as a universal rule for every current vSphere version. Before deployment, check the release-specific documentation and the VMware Compatibility Guide for supported vCPU counts, guest operating systems, virtual disks, device types, processors, host hardware, and feature combinations.
Cluster-level requirements
- Provide at least two ESXi hosts capable of participating in FT. The primary and secondary VM must be able to run on separate hosts.
- Place the protected VM's configuration files and virtual disks on common storage that every eligible host can access.
- Ensure consistent connectivity across participating hosts for VM networks and required management services.
- Configure both FT logging and vMotion networking on every participating host.
- Enable vSphere HA on the target cluster.
- Use hosts that are FT-certified and share the same supported FT version or a compatible ESXi build level.
- Keep vCenter Server host certificate checking enabled. In the referenced vCenter Server generation, this setting is enabled by default; verify it rather than assuming the default remains unchanged.
Cluster membership alone does not prove FT readiness. Each possible host for the primary or secondary VM must meet the processor, build, certification, network, storage, and licensing requirements.
ESXi host requirements
Processor and firmware compatibility
Participating hosts need processors in an FT-compatible processor group. Processor compatibility matters because the secondary VM must execute the same protected workload in lockstep with the primary. Differences in processor capabilities can prevent a host from safely running the secondary.
Hardware virtualization (HV) must be enabled in the server BIOS or UEFI. Depending on the processor platform, this is commonly exposed as Intel VT-x or AMD-V. Enabling the setting in firmware is not sufficient by itself: the host model, processor, adapters, and ESXi combination must also be supported for FT.
Certification and licensing
- Check the host and server hardware in the VMware Hardware Compatibility List or VMware Compatibility Guide.
- Confirm that the processor combination is supported for the relevant FT version.
- Keep ESXi releases and build levels within a documented compatible combination.
- Confirm that the assigned vSphere licensing entitlement includes Fault Tolerance.
Network requirements
FT logging
FT logging is the synchronization traffic exchanged between the hosts running the primary and secondary VM. It needs reliable, low-latency connectivity and adequate bandwidth. Packet loss, congestion, inconsistent MTU settings, VLAN errors, or an overloaded path can reduce reliability or prevent FT from operating.
vMotion and VM networks
A configured vMotion network is also required by the historical FT configuration. Each participating host needs a VMkernel adapter with vMotion enabled. The hosts must also provide consistent VM port groups on every location where either the primary or secondary VM may run.
A common design separates or appropriately isolates management, vMotion, FT logging, production VM traffic, and shared-storage traffic. This can use separate VMkernel adapters, VLANs, uplinks, or physical network paths when the design requires it. The important result is predictable reachability, sufficient capacity, and consistent configuration on all eligible hosts.
VMkernel validation
- Verify a vMotion-enabled VMkernel adapter on every participating host.
- Verify an FT-logging-enabled VMkernel adapter on every participating host.
- Test end-to-end connectivity between the FT logging interfaces.
- Check VLAN, uplink, switch, routing, and MTU consistency.
- Reserve suitable capacity so synchronization traffic does not excessively contend with unrelated traffic.
Shared storage requirements
All VM configuration files and virtual disks must reside on shared storage visible to every eligible FT host. Both the primary and secondary VM depend on common storage accessibility during normal operation and failover.
In the historical FT scope, supported shared-storage protocols include Fibre Channel, Fibre Channel over Ethernet (FCoE), iSCSI, and NFS.
| Storage Type | Historical Support | Planning Notes |
|---|---|---|
| Fibre Channel | Supported | Present the required datastore consistently to every eligible host. |
| Fibre Channel over Ethernet | Supported | Validate both storage connectivity and the supported host and adapter combination. |
| iSCSI | Supported | Check datastore visibility, paths, and consistent host access. |
| NFS | Supported | Mount the same datastore and verify access from all potential primary and secondary hosts. |
The historical virtual disk requirements specify thick-provisioned virtual disks or virtual-mode raw device mappings (RDMs). A thick-provisioned VMDK allocates its configured capacity on the datastore. A virtual-mode RDM presents a mapped storage LUN through a virtual disk layer.
Physical-mode RDMs are not supported by the historical FT requirements. The historical scope also limits VMDKs to 2 TB or smaller. Validate disk format, RDM mode, and capacity against the documentation for the exact vSphere release before using these limits as a deployment rule.
Virtual machine eligibility requirements
The candidate VM must use a supported guest operating system and supported virtual hardware. Review the VM before enabling FT rather than relying only on the cluster's status.
| VM Attribute | Historical Support Status | Required Action or Limitation |
|---|---|---|
| vCPU count | One vCPU in the historical implementation | Check the current release documentation; this is not a universal current-version rule. |
| Guest OS | Supported guest operating systems only | Validate the exact OS and release in the VMware Compatibility Guide and product documentation. |
| Snapshots | Not eligible before enabling FT | Remove or consolidate snapshots first. |
| Linked clones | Not eligible | Use a supported independent VM arrangement. |
| Disk provisioning | Thick-provisioned VMDKs supported historically | Check the disk format against release-specific requirements. |
| Virtual-mode RDM | Supported historically | Validate the RDM and storage combination. |
| Physical-mode RDM | Not supported historically | Redesign the storage dependency where appropriate. |
| VMDK capacity above 2 TB | Not supported historically | Confirm current capacity limits before deployment. |
| USB devices | Not eligible historically | Remove the device or use a supported alternative. |
| Sound devices | Not eligible historically | Remove the device if FT is required. |
| Serial ports | Not eligible historically | Remove or redesign the dependency. |
| Parallel ports | Not eligible historically | Remove or redesign the dependency. |
Also review other unsupported virtual hardware and configuration features identified by the applicable release documentation. The VM should be clean, supported, and able to run equivalently on both eligible hosts.
Requirements by layer
| Layer | Requirement | Reason | Validation Method |
|---|---|---|---|
| Cluster | At least two compatible FT-capable hosts, HA enabled, compatible builds, and certificate checking enabled | The primary and secondary need separate qualified hosts managed in a supported cluster | Review cluster settings, host inventory, build levels, and vCenter security settings |
| ESXi host | FT-compatible processor group, enabled HV, certification, and licensing | Both hosts must execute the same workload safely | Check firmware, hardware compatibility, ESXi version, and license assignment |
| Network | FT logging and vMotion VMkernel services plus consistent VM port groups | Synchronization, migration, and VM connectivity depend on reliable paths | Inspect VMkernel settings and test connectivity between hosts |
| Shared storage | Common datastore access using a supported storage design | Both VM copies need access to the protected VM files | Confirm datastore mounts, permissions, paths, disk formats, and capacity |
| Virtual machine | Supported guest OS, hardware, disks, and configuration with no snapshots or linked-clone dependency | FT supports only eligible VM configurations | Inspect VM settings, snapshots, clone status, devices, disks, and vCPU count |
| Licensing and compatibility | Appropriate FT entitlement and supported feature combination | Technical readiness cannot compensate for an unsupported edition or combination | Review license inventory and VMware compatibility references |
Pre-deployment validation workflow
- Validate hardware: Check host certification, processor compatibility, server and adapter support, and BIOS or UEFI hardware virtualization settings.
- Validate licensing: Confirm that the hosts and cluster have an entitlement that includes Fault Tolerance.
- Validate the cluster: Enable vSphere HA and confirm that at least two compatible FT-capable hosts are available.
- Validate versions: Compare ESXi versions, build levels, processor groups, VM hardware version, and the supported FT combination for the target release.
- Validate storage: Confirm that every participating host can see and access the shared datastore containing all VM files and disks.
- Validate networking: Confirm vMotion and FT logging VMkernel adapters on every host. Test reachability, VLANs, MTU, bandwidth, and port-group consistency.
- Inspect the VM: Check vCPU count, guest OS, snapshots, linked-clone status, virtual disk type, disk capacity, RDM mode, and USB, sound, serial, and parallel devices.
- Enable FT last: Configure FT only after cluster, host, storage, network, licensing, and VM checks pass.
Practical validation examples
Eligible historical FT workload
A business application VM has one vCPU, a supported guest OS, thick-provisioned VMDKs below the historical 2 TB limit, no snapshots, and no USB, sound, serial, or parallel devices. Its files are on an NFS datastore mounted by two compatible, FT-certified ESXi hosts. HA is enabled, and both hosts have vMotion and FT logging VMkernel networking. This VM passes the major historical eligibility checks, subject to release-specific validation.
VM rejected because of configuration
A VM has an active snapshot and a physical-mode RDM. Correctly configured hosts and networks do not make this VM eligible under the historical requirements. Consolidate or remove the snapshot and redesign the physical-mode RDM dependency using a supported storage configuration where appropriate.
Cluster without complete datastore access
Two hosts belong to the same cluster, but one cannot see the datastore containing the candidate VM. The cluster is not ready for FT for that VM. Every potential primary and secondary host must have access to the required shared datastore.
Network design validation
Each FT-capable host has VMkernel services for vMotion and FT logging. The administrator verifies end-to-end reachability, consistent VLAN and MTU settings, and adequate bandwidth before enabling FT. Synchronization traffic is given suitable isolation or capacity so that unrelated workloads do not overload the path.
Troubleshooting FT readiness problems
FT cannot be enabled because no compatible host is available
Likely causes include having only one FT-capable host, incompatible processor groups or ESXi builds, missing certification, or insufficient licensing.
- Verify that at least two eligible hosts are available.
- Compare processor compatibility, ESXi build compatibility, and VMware Compatibility Guide results.
- Correct licensing or move the workload to a properly qualified cluster.
FT enablement fails because of VM configuration
Check for snapshots, linked clones, physical-mode RDMs, unsupported virtual devices, historical vCPU limits, and VMDKs exceeding the historical 2 TB limit.
- Review VM settings and remove unsupported devices.
- Consolidate snapshots.
- Replace unsupported disk or clone arrangements with supported alternatives.
- Confirm release-specific VM limits before trying again.
The secondary VM cannot access files or networks
Common causes are an unmounted datastore, inconsistent port groups, or missing or misconfigured FT logging and vMotion networks.
- Verify shared datastore visibility and permissions on every participating host.
- Standardize port-group, VLAN, and uplink configuration.
- Validate the vMotion and FT logging VMkernel services and end-to-end connectivity.
FT logging network problems reduce reliability
Insufficient bandwidth, VLAN mismatches, MTU inconsistency, routing errors, network isolation, or an overloaded shared path can affect FT logging.
- Test connectivity between FT logging interfaces.
- Verify VLAN, uplink, switch, and MTU configuration on every host.
- Provide appropriate bandwidth and isolate synchronization traffic when required by the design.
FT readiness checklist
| Check | Expected Result | Status |
|---|---|---|
| Two or more compatible FT hosts | At least two certified, processor-compatible hosts are available | ☐ |
| HA enabled | vSphere HA is enabled on the target cluster | ☐ |
| FT logging configured | Each participating host has a reachable FT-logging VMkernel service | ☐ |
| vMotion configured | Each participating host has a working vMotion VMkernel service | ☐ |
| Shared datastore visibility | All eligible hosts can access every required VM file and disk | ☐ |
| Host certification | Hardware and adapters appear in the applicable compatibility reference | ☐ |
| Hardware virtualization enabled | VT-x or AMD-V is enabled in BIOS or UEFI | ☐ |
| FT licensing | The assigned entitlement includes Fault Tolerance | ☐ |
| Eligible VM configuration | No unsupported snapshots, clones, devices, disks, or release-specific limits | ☐ |
Key exam and planning notes
- FT uses a primary VM and a synchronized secondary VM; HA restarts a VM after failure.
- HA is required for the historical FT cluster configuration, but HA alone does not provide FT continuity.
- FT requires at least two qualified hosts, common storage, FT logging, vMotion, compatible processors and builds, supported hardware, and appropriate licensing.
- The one-vCPU, 2 TB VMDK, device, RDM, and disk-format limits listed here are historical and release-dependent.
- Snapshots and linked-clone VMs are not eligible under the historical requirements.
- Always use the VMware Compatibility Guide and release-specific documentation for the final decision.
For a concise reference, use the vSphere FT requirements checklist while validating each layer of the design.