
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”.
I then created (2) Resource Pools with default settings on this new host: ‘App01’ & ‘App02’.
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.
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.
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:
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:
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!!!