6.5.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.
N You can also use VM-Host anity 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 aected by such a rule, its associated
Secondary VM is also aected by that rule. For more information about anity 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 le 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 dierent technology for Fault Tolerance (now known as
legacy FT), with dierent 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 seing of an advanced option for each VM. See “Legacy Fault Tolerance,” on
page 53 for more information.
Fault Tolerance Use Cases
Several typical situations can benet 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 reentered or reloaded. Failover provided by vSphere HA restarts the
virtual machines aected 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 which must always be available, especially applications 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 congure 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 running a quarter-end report which, if interrupted, might delay the availability
of critical information. With vSphere Fault Tolerance, you can protect this virtual machine before running
this report and then turn o 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
42 VMware, Inc.