There are no lack of articles on the subject of VMware resource pools and shares, yet I am constantly amazed by how frequently they are misused.  This isn’t just a problem in the SMB either.   Resource pool abuse is an equal opportunity virtual infrastructure killer and I feel the need to dredge up the tired topic again in the hope of reaching at least one more vSphere administrator.

 Resource pools can be a very powerful tool that helps an organization achieve very aggressive CPU and Memory utilization.  Properly configured resource pools ensure that cluster resources are intelligently allocated during times of contention.  Critical virtual machines can be given preferential access to compute in the form of shares and/or reservations, while less critical virtual machines, with fewer shares, will receive fewer CPU cycles and less access to memory.  Sadly, they are often improperly configured and can have quite the opposite effect.

Resource pools should not be used to simply organize your VMs.  I have seen large vSphere implementations where VMs are organized into Pools named after their application, performance, or DR tiers, without any thought to the effect on share values.  This can create unbalanced resource pools and have unintended consequences.  Use folders to organize your VMs and delegate permissions instead.

The most common example of this misconfiguration I see is the old “High, Normal and Low” design, where three sibling pools are created that are given default High, Normal and Low shares with no reservations and named accordingly.  Craig Risinger does an excellent job of explaining and illustrating the issue in his posting The Resource Pool Priority-Pie Paradox.  Many a well-meaning engineer has implemented this design under the mistaken assumption that this will ensure that VMs in the High pool will always receive higher shares to resources than the Normal and Low.  Not so fast!  In our example, sibling resource pools are given 8,000, 4,000 and 2,000 CPU shares or 57%, 29% and 14% of total cluster CPU respectively to split among their member VMs.  All works as expected as long as there is an equal number of VMs in each pool (Table A), but when the cluster becomes unbalanced (Table B), our Low Priority VMs wind up with 2.5 times the access to CPU.

Note: This example illustrates our problem using CPU shares and assumes a single vCPU/VM for simplicity.  The issue is true of memory shares as well, with a ratio of 4:2:1.

Table A – Balanced Resource Pool, Default Shares

Table B – Unbalanced Resource Pool, Default Shares

Chris Wahl explains how to maintain cluster balance in his article Understanding Resource Pools in VMware vSphere  using Custom Share Values, and he even provides a sample PowerCLI script to help automate the process.  This is not a one-time process.  vSphere Admins need to constantly monitor their clusters and adjust these values as VMs are moved in and out of the pools.  In order to make our High, Normal and Low pools work as expected we need to assign custom CPU shares as detailed in Table C.

Table C – Unbalanced Resource Pool, Custom Shares

Now that you have your resource pools configured with appropriate custom share values, make sure you don’t make the other most common mistake: placing VMs in the Root resource pool.  Eric Sloof, in his article Don’t add resource pools for fun, they’re dangerous, shows how a few casually misplaced VMs placed in the root resource pool (these VMs become siblings of large resource pools) can provide them with an inordinate amount of % shares.

Please note that VMware resource management is not limited to shares.  An effective resource management strategy could include reservations, along with network and storage I/O control, though each is worthy of more attention than is feasible in a blog posting.  Thank you for listening to this public service announcement; I hope it helps you when architecting your own resource pool designs.