Resource Pools are NOT for Everyone

VMware Resource Pools are not something that should be thrown into every vSphere implementation!  I considered not writing this post, because of all of the blogs I’ve seen that have written about this already.  If you don’t believe me, check out a few of these:

http://www.ntpro.nl/blog/archives/1512-dont-add-resource-pools-for-fun,-theyre-dangerous.html

http://wahlnetwork.com/2012/02/01/understanding-resource-pools-in-vmware-vsphere/

http://www.yellow-bricks.com/2009/11/13/resource-pools-and-shares/

http://frankdenneman.nl/2010/05/18/resource-pools-memory-reservations/

Unfortunately, I continue to hear resource pools being misunderstood.  Don’t get me wrong, these are great tools and have a place in your arsenal, but they are used for a very specific reason.

I’m rarely asked about resource pools because they seem very straightforward.   The VMware customers I’ve worked with usually think it’s a good idea to put in a rule to handle situations when resource contention occurs.  This usually means a pair of resource pools for Production and a second one for LabDevTest etc.

Problem:  In the event that I have resource contention, I want my production machines to have more access to the physical machine hardware.

Witnessed solution:  Two resource pools are created and one of which has the production servers in it.  The production resource pool having a higher number of shares than the secondary resource pool

Problem with the witnessed solution:  A resource pool share setting stays the same no matter what number of virtual machines are housed in it.  Let me provide a very simplistic example.

Physical Resources:

–        10 CPUs

–        100 GBs of RAM

Resource Pools

–        Production (High Shares of CPU and Memory – 4000)

–        Lab (Low Shares of CPU and Memory – 1000)

Virtual Machines

–        100 virtual machines in production resource pool

–        1 virtual machine in the lab resource pool

The production Resource pool has 10 CPUs * 4000 shares = share value of 40000 and 100 GBs * 4000 shares = share value 400000

The lab resource pool has 10 CPUs * 1000 shares = share value of 10000 and 100GBs * 1000 shares = share value 10000

So to break this down we have

Many customers at this point don’t see the issue yet.  But, look what happens when you look at the amount of shares / virtual machine!

Net results show that each virtual machine in the production resource pool gets 4000 shares of CPU and 40,000 shares of memory compared to the Lab resource pool virtual machines that get 10000 shares of CPU and 100,000 shares of memory!

This is not what customers are intending to do.

The answer to how to fix this can be found on Chris Wahls  site http://wahlnetwork.com/2012/02/01/understanding-resource-pools-in-vmware-vsphere/ where Chris expertly demonstrates the correct way to figure out the math on resource pools and better yet, shows how to dynamically keep these pools in check by using a powerCLI script.

My point is, be sure you’re not just throwing in resource pools without doing some calculations before hand.