If more servers fail than have been planned for, then an HA recovery operation begins. The HA restart priority is used to determine which VMs are restarted, while the order in which individual VMs are started is determined by their start order and delay interval values, ensuring that the most important VMs are restarted first.
HA restart priority
The HA restart priority specifies which VMs will be restarted under the HA failure plan for a pool:
|Restart||VMs with this priority are guaranteed to be restarted if sufficient resources are available within the pool. They will be restarted before VMs with a Restart if possible priority. All VMs with this restart priority are considered when calculating a failure plan. If no plan exists for which all VMs with this priority can be reliably restarted, then the pool is considered to be overcommitted.|
|Restart if possible||VMs with this restart priority are not considered when calculating a failure plan, but one attempt to restart them will be made if a server that is running them fails. This restart is attempted after all higher-priority VMs are restarted, and if the attempt to start them fails, then it will not be retried. This is a useful setting for test/development VMs which aren’t critical to keep running, but would be nice to do so in a pool which also has some important VMs which absolutely must run.|
|Do not restart||No attempts will be made to restart VMs with this priority.|
The Restart order specifies the order in which individual VMs will be started up during an HA recovery operation, allowing certain VMs to be restarted before others. VMs with a restart order value of 0 (zero) will be started first, then VMs with a restart order value of 1, followed by VMs with a restart order value of 2, and so on.
Delay interval (Attempt to start next VM after)
The VM property Attempt to start next VM after specifies how long to wait after starting the VM before attempting to start the next group of VMs in the startup sequence, that is, VMs with a later restart order.