I know there have been numerous blog posting on this topic already which are all very good, but this is mainly for my own understanding as I try to understand this topic a bit further.
So what are resource pools?
They are a logical abstraction for management so you can delegate control over the resources of a host (or a cluster). They can be grouped into hierarchies and used to progressively segment out accessible CPU and memory resources.
Resource pools use a construct called shares to deal with possible contention (noisy neighbor syndrome)
|Setting||CPU share values||Memory share values|
|High||2000 shares per vCPU||20 shares per megabyte of configured VM memory|
|Normal||1000 shares per vCPU||10 shares per megabyte of configure VM memory|
|Low||500 shares per vCPU||5 shares per megabyte of configured VM memory|
*Taken from the 5.5 vSphere Resource Management document
My biggest issue with even getting into any contention issues is why would you architect a design that has the possibility to have contention if you can avoid it. I understand that a good design takes into account for the worst case scenario in which all VMs would be running at 100% of provisioned resources, therefore possibly generating an over-commitment issue with potential contention but that’s when you go to the business to request more funds for more resources. I know it’s the one of the benefits of virtualization that you can do this, but should you rely on it?.. It’s also a comfort level of over allocation in which the level depends on the individual architect. Keep to the rule of protecting the workload and I don’t see an issue with this. I keep the worst case scenario in mind, but I don’t ever want to get there, but this is more of a rant than anything else.
Frank Denneman(@FrankDenneman), Rawlinson Rivera(@PunchingClouds), Duncan Epping(@DuncanYB) and Chris Wahl(@ChrisWahl) have already set us straight on the impacts of using resource pools incorrectly and the best ways to most efficiently use RPs.
The main takeaways of resource pools are:
- Don’t use them as folders for VMs
- Don’t have VMs on the same level as resource pools without understanding the impacts
- If VMs are added to the resource pools after the shares have been set, then you’ll need to update those share values
- Don’t go over eight (8) levels deep [RP limitation; and why would you]
Chris Wahl: Understanding Resource Pools in VMware vSphere
Frank Denneman and Rawlinson Rivera: VMworld 2012 Session VSP1683: VMware vSphere Cluster Resource Pools Best Practices
Duncan Epping: Shares set on Resource Pools