I had question today about using the advanced settings to set a minimal amount of resources that HA would use to do the admission control math with. Many of us have used these advanced settings das.vmMemoryMinMB and das.vmCpuMinMHz to dictate the slot size when no reservations were set in an environment where the “host failures” admission control policy was used. However what many don’t appear to realize is that this will also work for the Percentage Based admission control policy.
If you want to avoid extreme overcommitment and want to specify a minimal amount of resources that HA should use to do the math with then even with the Percentage Based admission control policy you can use these settings. In the case where your VM reservation does not exceed the value specified, the value is used to do the math with. In other words if you set “das.vmMemoryMinMB” to 2048, it will use 2048 to do the math with unless the reservation set on the VM is higher.
I did a quick experiment in my test lab which I had just rebuilt. Without das.vmMemoryMinMB and two VMs running (with no reservation) I had 99% Mem Failover Capacity as shown in the screenshot below:
With das.vmMemoryMinMB set to 20480, and two VMs running, I had 78% Mem Failover Capacity as shown in the screenshot below:
I guess that proves that you can use das.vmMemoryMinMB and das.vmCpuMinMHz to influence Percentage Based admission control.
Very timely post Duncan, I was just discussing this exact topic for a solution im developing at the moment. You have saved me some time testing, cheers.
For those who may be interested, I have posted an Example Architectural Decision relating specifically to these settings http://t.co/4rTDpKfSur
Hi Duncan,
I’m not clear of the use of these settings vs using the “das.slotmeminmb” and “das.slotcpuinmhz”
Can you explain?
You use “das.vmMemoryMinMB and/or das.vmCpuMinMHz” when you want to increase the minimum resource values that HA uses to calculate how many VMs can be powered on in a cluster.
If you set no reservation on VMs then extremely low values could be used, potentially resulting in extreme overcommitment. By bumping these values up, you artificially limit the amount of VMs and as such prevent extreme overcommitment.
Thanks Duncan, that part is understood (even better now), and I see how that would make sense when using % based admission control, but in your article you mention these settings were commonly used for Host Failure Admission Control. I’ve never used these for Host Failure, I always used “das.vmMemoryMinMB”, so now I’m confused on whether I’ve been doing it wrong
Great info, thought it was only for min slot calculation when “number of hosts” was used as HA admission control policy!
das.vmMemoryMinBM and das.vmCPUMinMhz tells HA to think the reservation is high forcing each VM’s usage to appear to be at least this amount. This effects what admission control uses to calculate available resources. Otherwise % of resources uses active memory and cpu. So this would only effect the usage calculated for VMs who’s active memory/cpu is lower than the artificial reservation set by these parameters.
“das.slotmeminmb” and “das.slotcpuinmhz” only effect HA admission when # of hosts is selected by setting a minimum on the slot size. All VMs are assumed to be the size calculated by the slot size. The other two would also affect the slot size by inflating the reservation seen by HA.
Hi,
Not sure what you are referring to, but let me clarify some things here:
1) percentage of resources does not use active memory or cpu! It uses the reservation. The advanced setting sets the lowest boundary, if reservation set is higher then that is used. If active memory is higher then… Nothing… Active is not used ever.
2) the das.slotmemin* settings define the upper boundary. If you set das.slotmeminmb to 2gb and you have a 4gb reservation then 2gb is what the slotsize will be.