VM /ETC

How do you design resource pools in an ESX Cluster? There are two strategies that are the most popular in my experience. The first strategy creates resource pools based on CPU and Memory shares for host resource conflict management, and the second strategy uses reservations and limits to guarantee physical resources and ensure VM containment. This post will use a 3 ESX host example to explain both strategies. Please feel free to comment on the pros and cons of each or why you think one is better than the other.

In the example scenario three ESX hosts each have 16 GB RAM and 2 dual core 3.0 Ghz CPUs. The three hosts will all be members of the same ESX cluster.

I tried to create design names that illustrate the strategy. I am not aware of any specific resource pool design naming from VMware.

The Tug of War design

This design is simple and does not limit any VMs from any physical resources. Using the ESX shares mechanism, if two or more VMs are competing for the same physical resources the tug of war that results will be decided by the resource pool memberships of the VMs.

The ESX cluster will have three resource pools defined.

• A “High” resource pool will have no initial reservation and unlimited/expandable RAM and CPU settings. CPU and Memory shares will be set to high. This resource pool will be devoted for mission-critical VMs.
• A second “Normal” resource pool will have no initial reservation and unlimited/expandable RAM and CPU settings. CPU and Memory shares will be set to normal. Normal priority service VMs will be placed into that resource pool and the shares guarantee that VMs in this resource pool do not have priority over mission critical VMs.
• A third “Low” resource pool will have no initial reservation and unlimited/expandable RAM and CPU settings. CPU and Memory shares will be set to low. Low priority service VMs, development, and non critical VMs will be placed into this resource pool and the shares guarantee that VMs in this resource pool do not have priority over normal or high VMs.

The three resource pools configured by shares will ensure that the proper VM has priority to physical resources when a conflict occurs. Resource conflict management can take place with the full capacity of the ESX cluster’s physical resources.

The Pizza Design

updated 03.09.08

This design takes the sum total of all physical resources and slices it up across the resource pools. Although the following design only uses two resource pools, many more “slices” could be created. The most basic Pizza Design would be to reserve all memory and cpu, but the following example helps also illustrate reservations and limits.

The ESX cluster will have two resource pools defined.

• A “Critical Services” resource pool will have an initial reservation of 32GB RAM and 8GHz CPU, and unlimited/expandable RAM and CPU settings. This resource pool will be devoted for mission-critical VMs. Shares for RAM will be set to high, but shares for CPU will be set to normal.
• A second “Non Critical Services” resource pool will have no reservation and a limit of 16GB RAM and 4GHz CPU. Shares for Memory and CPU will be set to normal. Low priority service VMs will be placed into this resource pool and the limits guarantee that VMs in this resource pool do not over consume resources.
• The remaining balance of CPU is fully available to the Critical Services pool because of the expandable reservation.

This specific design example was based on a mix of VMs that were expected to contend for memory more often then cpu.

Final Thoughts

I usually start a design with the tug of war strategy. Resource Pools can be confusing, complicated, and difficult to troubleshoot if the design gets complex. Starting out simple makes sense until a specific VM performance issue is determined. On the other hand, the pizza design is a better starting point if you know you will have heavily used development VMs mixed in with your production VMs. The pizza design ensures that if a developer launches a rogue script on one of the VMs then the production system will not be impacted.

LOL! After writing this I am hungry for some pizza ….

Related Posts

• Planning ESX host capacity (3)
• Simply Automating Virtual Machine IP Addressing For Disaster Recovery Sites (without scripting) (15)
• Can you Vmotion between different physical data centers? (2)
• Create guest priorities on VMware Server (1)
• Create a vcbuser – VCB Best Practice (4)
• ESX NIC Teaming and VLANs (0)
• Design a clustered VM application that can fully leverage VMotion, DRS, and HA? (7)
• 24 Hour Timeout Prevents Removing ESX vNetwork Distributed Switch (0)
• Don’t Hit Ctrl+Alt+Del On the ESX 4 Console (14)
• vCenter 4 and ESX 4 Now Use 10 Year Default SSL Certificate (7)