VMware resource pools are a bit weird. They don’t work the way you would assume them to, so it is easy to get the wrong. This article details quite simply how you can use them for an example to illustrate this I will use my live production environment to illustrate how and how not to calculate the resource pool figures and configure them correctly.
Resource Pool Rule #1: Don’t use the default “High”, “Normal” or “Low” settings for the shares for CPU or RAM, these will almost always be completely wrong for your environment.
Resource Pool Rule #2: Lots of stuff in VMware is automatic self-levelling (like DRS), so its understandable that people will assume that resource pools are the same, unfortunately not, you need to tune them constantly as you add or remove VMs to ensure they are kept in best form.
Resource Pool Rule #3: Decide on how you want to divvy up the resources (shares) to each VM first, then worry about the way to configure the Resource Pools second.
Resource Pool Rule #4: The shares in a pool are divvyed up equally between the number of VMs in the pool. So if I have a resource pool with 100 CPU/RAM shares, and within it 10VMs, each VM gets 10 shares. If I have a resource pool with 100 CPU/RAM shares and 5 VMs in it, each VM gets 5 shares.
Right, the environment I have 5 x ESX hosts, each with 128GB of RAM and 2 x 10 Core CPUs. So in total I have within the cluster:
100 CPU Cores
640GB Ram
I have running on this cluster:
27 High Priority VMs
14 Normal Priority VMs
22 Low Priority VMs
The design I want is that a “High Priority” VM should get twice as many shares as a “Normal Priority” VM, which should then get twice as many shares as a “Low Priority” VM.
Now the shares for CPU and RAM, the biggest takeaway with this is that the figure is not a magic number it is a just a number, the exact number doesn’t matter what matters is the ratio with the other share values for the other resource pools. Okay right to explain: lets say we want our “High Priority” VMs to have 100 CPU/RAM Shares, so to give “Normal Priority” VMs half the amount of resource, we would set these to 50 CPU/RAM shares, and then finally to give “Low Priority” VMs half of the normal, we would give these 25 CPU/RAM Shares. So we would end up with this for the shares for each VM:
High Priority VM: 100 CPU Shares & 100 RAM Shares
Normal Priority VM: 50 CPU Shares & 50 RAM Shares
Low Priority VM: 25 CPU Shares & 25 RAM Shares
(Bear in mind we could use 10, 5 and 2 (and a half! 🙂 ) and would get the same result)
Now we have what we want for the shares we can now calculate what we need to set on the resource pools. Here we are working back from the shares on the VMs.
So…..Based on my example above, we plug in the figures and get this:
27 High Priority VMs x 100 CPU/RAM Shares = 2700 CPU/RAM Shares
14 Normal Priority VMs x 50 CPU/RAM Shares = 700 CPU/RAM Shares
22 Low Priority VMs x 25 CPU/RAM Shares = 550 CPU/RAM Shares
So the 2700, 700 and 550 are the share values for CPU/RAM we need to set on our High, Normal and Low resource pools respectively. Not too shabby right. Now the total number of CPU/RAM shares for the cluster is: 2700+700+550 = 3950 shares. High priority VMs get 68% of the total resources, Normal priority VMs get ~18% and Low Priority get about 14%.
Okay another example, my other site cluster (used for disaster recovery and production) has the same number of hosts and RAM, but fewer core only 40 in total. Again I want the same ratio of shares to high, normal and low as before so: 100, 50 and 25 of shares per VM. Working this out I now get:
2 High Priority VMs x 100 CPU/RAM Shares = 200 CPU/RAM Shares
1 Normal Priority VMs x 50 CPU/RAM Shares = 50 CPU/RAM Shares
2 Low Priority VMs x 25 CPU/RAM Shares = 50 CPU/RAM Shares
Well would you take a look at that, you can see now exactly what is going on there, the normal and low have the same 50 Shares, the different therefore is in the number of VMs in the resource pool. Who would have thought. So the low priority pool has 50 shares to it, and each VM only get 25 each. While the Normal priority pool has 50 shares on it, and each VM gets (only the 1) gets 50 shares each.
Although that looks counter intuitive it is actually correct. Of course, if you were to move one VM from Low to Normal, you’d need to recalculate the resource pool settings and reconfigure them!
=============================================================================================================
Now lets see about how to do it wrong. The bit below here is now not what to do!
Lets say we just go with the VMware defaults for High, Normal and Low, so: 8000, 4000, 2000 respectively, how many shares does each VM get now?
The / means divided by…..
8000 CPU/RAM Shares / 27 = 296 Shares per VM
4000 CPU/RAM Shares / 14 = 285 Shares per VM
2000 CPU/RAM Shares / 22 = 90 Shares per VM
So what do you notice about the bits in red, 296 is not a lot bigger than 285 for the normal VMs. Hmm, I wanted the number of shares per VM to be half didn’t I?! Here you can see the issue. If I was to remove 7 VMs from the Normal resource pool and put them into the High say, the issue gets even worse like this:
8000 CPU/RAM Shares / 34 = 235 Shares per VM
4000 CPU/RAM Shares / 7 = 571 Shares per VM
Blimey, so now if we moved the VMs and didn’t update the resource pool shares, in a period of contention our Normal VMs would get more resource than the High VMs. Oh dear.
Resource Pools are only used when there is contention, if you’ve got plenty of resource it doesn’t matter. A resource pool with few shares divided by a small number of VMs can give more shares per VM, than a resource pool with lots of shares, but also lots of VMs in it.
http://www.yellow-bricks.com/2010/02/22/the-resource-pool-priority-pie-paradox/
http://wahlnetwork.com/2012/02/01/understanding-resource-pools-in-vmware-vsphere/
