Performance Impacts from Grouping VMs in Resource Pools

Categories Building Clouds (Technology)
Resource Pools

About a year ago I had a customer ask me if grouping VMs in Resource Pools could impact performance and after seeing Frank Denneman‘s recent blog (The public Shaming of Resource Pool-as-a-Folder User) I figured I would write up a quick explanation.  I generally recommend my customers stay away from resource pools if at all possible unless they have specific use cases where it makes sense (think service provider where a tenant/customer is paying for a specific amount of resources).

Can VM performance be impacted by logically grouping them in Resource Pools?

The short answer is… YES absolutely!  The long answer is… it depends.  It depends on whether or not your environment is suffering from resource contention.  I setup a scenario in my lab to demonstrate this answer.  I will just focus on CPU performance to keep this blog short and sweet.

Lab Setup

I built a nested ESXi 6.7 host in my lab with 2 vCPUs, 4 GB of Memory, and a 100 GB VMDK to act as a local datastore.  Then I joined this host to vCenter and placed it in a host folder named “Test”.

Resource Pool Host Setup

I then created (2) Resource Pools with default settings on this new host: ‘App01’ & ‘App02’.

Resource Pool Settings

Then I provisioned a VM running Photon OS with 2 vCPUs and 4 GB of Memory.  I created a service in the VM that runs a script at startup that keeps the CPU busy (100%) for 90 seconds.  I then converted this VM to a template and created a total of (8) VMs from this template on my host.  The first (7) VMs were placed in the ‘App01’ Resource Pool while the 8th VM was placed in the ‘App02’ Resource Pool.

Resource Pool VM Placement

VM Performance Under CPU Contention

To show the impact to CPU performance I logged into the host directly via SSH and opened an ESXTOP session.  I then powered-on all eight VMs at the exact same time.

PowerOn VMs

We should see CPU contention for the first 90 seconds while the CPUs are busy on each of the VMs.  Below is a screenshot from ESXTOP:

Contention Performance

Observe the %USED, %RUN, %RDY, %IDLE, & %CSTP values for ‘photon08’.  Even if you do not understand what these values represent (go here to learn), you can clearly see that ‘photon08’ is behaving differently than the other seven VMs.  %RDY is probably the biggest indicator of CPU performance (lower the better); therefore, ‘photon08’ is outperforming the other VMs because of the Resource Pool configuration.

VM Performance without CPU Contention

The host CPU is no longer under contention after the initial 90 seconds when the VM CPUs settle down.  Below is a screenshot of the VM performance from ESXTOP:

No Contention Performance

You can see that all eight VMs have very similar performance statistics because they are no under contention for CPU resources.

Conclusion

DO NOT USE Resource Pools to logically group your VMs!!!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.