VMTN user “ian4563” recently posted a thread about problems with the HA constraints. The error that was pulled from the log files:
Das admission check failed. Configured failover: 2, Expected new failover: 0
And the solution according to VMTN user “eziskind”, who also is a VMware employee:
Looks like you have some 4-cpu vms in the clusters too. That will really skew things. You’re being hit by the combination of 2 new things in the HA admission control for VC 2.5:
1) If no reservation is set for a vm (or it is set to 0), use default of 256MHz, 256MB. (these values can be changed using HA advanced options: das.vmMemoryMinMB, das.vmCpuMinMHz)
2) For the cpu component of the slot, use (max MHz per virtual cpu) * (max number of vcpu’s per vm)The HA admission control algorithm is overly conservative in non-homogenous clusters, ie. ones with vms which have different reservations and/or vcpu number. #2 above makes it more conservative. Given these limitations, its best to try to keep the cluster as homogenous as possible. Is it possible to put the 4-cpu vms in a separate cluster? If not, you can try setting the default vm resources to 0 (using the advanced options in #1). This is how things worked in VC 2.0.
Thanks goes out to my colleague Remco for pointing this topic out.
Does that mean that if you were to change the HA admission control to ‘Allow VMs to Violate’, this would not have been a problem? Most of my clients are more concerned during a failure to ‘get it back up’ rather than performance.
Carlo.
indeed, if you set it to “allow constraint violation” than it will definitely work.