6.0.1

Factors Considered for Virtual Machine Restarts
After a failure, the cluster's master host attempts to restart affected virtual machines by identifying a host
that can power them on. When choosing such a host, the master host considers a number of factors.
File accessibility
Before a virtual machine can be started, its files must be accessible from one
of the active cluster hosts that the master can communicate with over the
network
Virtual machine and
host compatibility
If there are accessible hosts, the virtual machine must be compatible with at
least one of them. The compatibility set for a virtual machine includes the
effect of any required VM-Host affinity rules. For example, if a rule only
permits a virtual machine to run on two hosts, it is considered for placement
on those two hosts.
Resource reservations
Of the hosts that the virtual machine can run on, at least one must have
sufficient unreserved capacity to meet the memory overhead of the virtual
machine and any resource reservations. Four types of reservations are
considered: CPU, Memory, vNIC, and Virtual flash. Also, sufficient network
ports must be available to power on the virtual machine.
Host limits
In addition to resource reservations, a virtual machine can only be placed on
a host if doing so does not violate the maximum number of allowed virtual
machines or the number of in-use vCPUs.
Feature constraints
If the advanced option has been set that requires vSphere HA to enforce VM
to VM anti-affinity rules, vSphere HA does not violate this rule. Also,
vSphere HA does not violate any configured per host limits for fault tolerant
virtual machines.
If no hosts satisfy the preceding considerations, the master host issues an event stating that there are not
enough resources for vSphere HA to start the VM and tries again when the cluster conditions have changed.
For example, if the virtual machine is not accessible, the master host tries again after a change in file
accessibility.
Limits for Virtual Machine Restart Attempts
If the vSphere HA master agent's attempt to restart a VM, which involves registering it and powering it on,
fails, this restart is retried after a delay. vSphere HA attempts these restarts for a maximum number of
attempts (6 by default), but not all restart failures count against this maximum.
For example, the most likely reason for a restart attempt to fail is because either the VM is still running on
another host, or because vSphere HA tried to restart the VM too soon after it failed. In this situation, the
master agent delays the retry attempt by twice the delay imposed after the last attempt, with a 1 minute
minimum delay and a 30 minute maximum delay. Thus if the delay is set to 1 minute, there is an initial
attempt at T=0, then additional attempts made at T=1 (1 minute), T=3 (3 minutes), T=7 (7 minutes), T=15 (15
minutes), and T=30 (30 minutes). Each such attempt is counted against the limit and only six attempts are
made by default.
Other restart failures result in countable retries but with a different delay interval. An example scenario is
when the host chosen to restart virtual machine loses access to one of the VM's datastores after the choice
was made by the master agent. In this case, a retry is attempted after a default delay of 2 minutes. This
attempt also counts against the limit.
Finally, some retries are not counted. For example, if the host on which the virtual machine was to be
restarted fails before the master agent issues the restart request, the attempt is retried after 2 minutes but
this failure does not count against the maximum number of attempts.
Chapter 2 Creating and Using vSphere HA Clusters
VMware, Inc. 17