6.0.1

A fault tolerant virtual machine and its secondary copy are not allowed to run on the same host. This
restriction ensures that a host failure cannot result in the loss of both VMs.
NOTE You can also use VM-Host affinity rules to dictate which hosts designated virtual machines can run
on. If you use these rules, be aware that for any Primary VM that is affected by such a rule, its associated
Secondary VM is also affected by that rule. For more information about affinity rules, see the vSphere
Resource Management documentation.
Fault Tolerance avoids "split-brain" situations, which can lead to two active copies of a virtual machine after
recovery from a failure. Atomic file locking on shared storage is used to coordinate failover so that only one
side continues running as the Primary VM and a new Secondary VM is respawned automatically.
vSphere Fault Tolerance can accommodate symmetric multiprocessor (SMP) virtual machines with up to
four vCPUs. Earlier versions of vSphere used a different technology for Fault Tolerance (now known as
legacy FT), with different requirements and characteristics (including a limitation of single vCPUs for legacy
FT VMs). If compatibility with these earlier requirements is necessary, you can instead use legacy FT.
However, this involves the setting of an advanced option for each VM. See “Legacy Fault Tolerance,” on
page 57 for more information.
Fault Tolerance Use Cases
Several typical situations can benefit from the use of vSphere Fault Tolerance.
Fault Tolerance provides a higher level of business continuity than vSphere HA. When a Secondary VM is
called upon to replace its Primary VM counterpart, the Secondary VM immediately takes over the Primary
VM’s role with the entire state of the virtual machine preserved. Applications are already running, and data
stored in memory does not need to be re-entered or reloaded. This differs from a failover provided by
vSphere HA, which restarts the virtual machines affected by a failure.
This higher level of continuity and the added protection of state information and data informs the scenarios
when you might want to deploy Fault Tolerance.
n
Applications that need to be available at all times, especially those that have long-lasting client
connections that users want to maintain during hardware failure.
n
Custom applications that have no other way of doing clustering.
n
Cases where high availability might be provided through custom clustering solutions, which are too
complicated to configure and maintain.
Another key use case for protecting a virtual machine with Fault Tolerance can be described as On-Demand
Fault Tolerance. In this case, a virtual machine is adequately protected with vSphere HA during normal
operation. During certain critical periods, you might want to enhance the protection of the virtual machine.
For example, you might be executing a quarter-end report which, if interrupted, might delay the availability
of mission critical information. With vSphere Fault Tolerance, you can protect this virtual machine prior to
running this report and then turn off or suspend Fault Tolerance after the report has been produced. You
can use On-Demand Fault Tolerance to protect the virtual machine during a critical time period and return
the resources to normal during non-critical operation.
Fault Tolerance Requirements, Limits, and Licensing
Before using vSphere Fault Tolerance (FT), consider the high-level requirements, limits, and licensing that
apply to this feature.
Requirements
The following CPU and networking requirements apply to FT.
vSphere Availability
46 VMware, Inc.