I received a question today about HA admission control policies, and more specifically about the “failover host” admission control policy. The question was why VMs were restarted on a different host then selected with the “Failover Host” admission control policy. Shouldn’t this policy guarantee that a VM is restarted on the designated host?
The answer is fairly straight forward, and I thought I blogged about this already but I cannot find it so here it goes. Yes, in a normal condition HA will request the designated failover host to restart the failed VMs. However there are a couple of cases where HA will not restart a VM on the designated failover host(s):
- When the failover host is not compatible with the virtual machine (portgroup or datastore missing)
- When the failover host does not have sufficient resource available for the restart
- When the virtual machine restart fails HA retries on a different host
Keep that in mind when using this admission control policy, it is no hard guarantee that the designated failover host will restart all failed VMs.
When VCenter is unavailable admission control policy is unavailable too and the VM get restarted on a different host.
That has got nothing to do with it… With or without vCenter the HA restart happens on a host layer and is not coordinated by vCenter at all at that point. There is a placement engine which handles this.
Whats about DRS affinity rules? Will the failover host “beats” the DRS rules or is it the other way around?
HA will not violate “must” rules but will violate “should” rules.
That’s interesting to know … do you find that “failover host” for HA is all that common? I admit that I have not seen it in a production environment.
Not common at all Chris. I hardly no any customer using it.