Label Resource Pools with Per VM Shares Value
If you’ll recall in my post “Understanding Resource Pools in VMware vSphere”, I cover the ideal of creating per VM share values to come up with a total number of shares for an entire resource pool. As an excerpt:
The trick to keeping your resource pools balanced is to work the math backwards and never, ever use the default high, normal, and low shares values. Decide the weight of your per VM shares first. Let’s say that I want my Dev/Test VMs to receive half as much share weight as Production. Instead of worrying about VMware’s default share value calculations above, create your own. Shares are an arbitrary value that just determine weight, they aren’t a magic number.
Now, knowing the per VM shares value works great for the lone wolf admin, but how do you easily communicate that to your entire team? Answer: Just tack the value on the resource pool name!
Simple and effective. Now you don’t even have to remember what the per VM shares are – when adding a VM to the pool, just read the RP name and do the multiplication.
I didn’t come up with this – kudos to Josh Doll for sharing this idea with me (and giving me permission to pass it along to you). Anything that makes administration easier is a thumbs up in my book. 
Simple, yet effective!
Love it!
Nice idea indeed! Thanks for sharing!
Shane
I see a problem with the article – the author does not take into account the number of VMs running in the cluster, just the number of VMs running in the resource pool. This means that his VMs will not necessarily be assigned resources as noted.
Resources in vSphere are allocated by proportional share. Proportional share means that out of a total number of shares available in a root resource pool (cluster, host, or resource pool), the resources running under that root resource pool (eg. VMs) are assigned “at least” that many shares. For example, from the article:
Bronze 50 shares
Silver 100 shares
Gold 200 shares
In this configuration, there are 350 shares (total). Under contention (either memory or CPU) this means that bronze is given (50/350 = 14.3% resources), silver is given (100 / 350 = 28.6% resources), and gold is given 57.1% of the resources – this is irregardless of the number of machines running in that resource pool. This, as Randy claims, is a longstanding problem. I tend to disagree. Let me show you why –
Consider the following configuration:
1 VMs in bronze (total shares in bronze 50), VM gets 14.3% resources (under contention)
1 VM in Silver (total shares in silver 100), VM gets 28.6% resources (under contention)
1 VM in Gold (total shares in gold 200), VM gets 57.1% resources (under contention)
Now consider that we add another VM to bronze and double the shares allocated to bronze (note now there will be 400 shares available instead of 350. As always, proportional share will be enforced, so we get the following:
2 VMs in bronze (total shares in bronze 100), each VM gets (50/400 = 12.5% resources)
1 VM in silver (total shares in silver 100), each VM gets (100/400 = 25% resources)
1 VM in gold (total shares in gold 200), each VM gets (200/400 = 50% resources)
See how adding one VM in bronze reduced the resources available under contention to gold by 7.1%? Also see how each VM in bronze now only gets 6.25% resources (each) (under contention)? If we take this argument to its logical conclusion, consider the following configuration:
200 VMs in bronze (total shares in bronze 10000), each VM gets (50/10300 = 0.484% resources)
1 VM in silver (total shares in silver 100), each VM gets (100/10300 = 0.97% resources)
1 VM in gold (total shares in gold 200), each VM gets (200/10300 = 1.94% resources)
Now consider this: the bronze pool now controls 97% of all cluster resources. You just starved silver and gold out by assigning all resources to bronze.
This is bad. When contention happens, you’ve now ensured that the VMs that you wanted to give more resources now have effectively very little.
So the question is now: When will this methodology that the article has recommended work properly? Generally speaking, if we have a roughly equal number of VMs per resource pool, this configuration will work as desired – the weights of the pools will remain roughly the same.
Wait a second… This puts us right back at the proportional share methodology that is actually recommended by VMware! To conclude, resource pools are great, but don’t try to outsmart them – you’ll shoot yourself in the foot.
To illustrate, consider proportional share with the original 50/100/200 configuration without multiplying that number by VM:
200 VMs in bronze (total shares 50) each VM gets 0.0714% resources
1 VM in silver (total shares 100) each VM gets 28.6% resources
1 VM in gold (total shares 200) each VM gets 57.1% resources
Now we haven’t starved our important VMs. Phew. The takeaway here is that the VMware shares calculation (High, Medium, Low) may not provide the breakdown that you need for proportional shares. Create your own custom shares levels to figure out percentages allocated to a tier (eg. gold, silver and bronze), but don’t multiply that number per VM – you’ll end up starving some subset of the resources in your cluster when things get unbalanced.
@Paul Miller
Thanks for taking the time to comment. I get what you’re saying, but I think you’re highlighting exactly what I’m trying to demonstrate. I’ll borrow part of your comment:
You’re flipping the idea of shares with reservations. No resources have been “assigned” to any of the pool, only the shares values for when contention occurs. The custom value is set in order to guarantee an agreed upon per-VM shares weight. As you show above, Bronze gets roughly 1/4 of the shares per VM to Gold (.484 vs 1.94). In a state of contention, the single Gold VM still has 4x more chance of receiving resources over Bronze and 2x more of a chance over Silver. While it’s true that the Bronze RP has many more total shares in the cluster (10,000 in Bronze vs 200 in Gold), it still has to be sliced up among 200 individual virtual machines (assuming they are all set to the default Normal shares within the RP).
Duncan Epping also did a great job writing on this topic here that may clear things up more: http://www.yellow-bricks.com/2010/12/14/shares-set-on-resource-pools/