By Need

By Industry

By Function

Infrastructure Modernization

When Bad Resource Pools Happen to Good People

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 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

Resource Pool CPU Shares/Pool # of VMs Relative CPU Shares/VM
High 8,000 100 80
Medium 4,000 100 40
Low 2,000 100 20


Table B – Unbalanced Resource Pool, Default Shares

Resource Pool CPU Shares/Pool # of VMs Relative CPU Shares/VM
High 8,000 100 80
Medium 4,000 200 20
Low 2,000 10 200


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

Resource Pool CPU Shares/Pool # of VMs Relative CPU Shares/VM
High 400 100 4
Medium 400 200 2
Low 10 10 1


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.

Tim Ferris.

Tim Ferris

Practice Manager – DC Modernization

Tim has over 20 years of combined technical, managerial, engineering, and analytical expertise.  After serving as IT Manager for several years at GreenPages, he moved into a delivery consulting role where he was a key contributor to our VMware delivery team, recognized by VMware as one of the leading delivery partners in the country.  Tim has extensive VMware and virtualization experience on large-scale projects for enterprise clients. He is also a subject matter expert in Data Protection and Storage with extensive experience designing and supporting large, complex, backup and disaster recovery environments.  ​

With a solid foundation in legacy datacenter technologies, Tim has expanded his skillset to include Cloud and Hybrid-Cloud architectures.  Tim holds numerous Azure, AWS and other industry certifications and is constantly learning in an effort to stay ahead of our rapidly evolving industry.