A common issue is that VMs are placed outside of any resource pools, leaving them at the same level as the highest level of user-created resource pools. For example, an administrator created two VMs named VM-1 and VM-2. The CPU shares on these VMs were left at the default “Normal” value, which is equivalent to 1000 CPU shares. These two VMs were placed at the top level of a DRS Cluster alongside two resources pools. One resource pool was named Sales and the other was named Finance, each having Normal Shares, which is equivalent to 4,000 CPU shares. The Limit and Reservation settings of each pool and VMs were left at default values. The administrator simply intended to implement containers for Sales and Finance VMs that could be used in the future to configure resources, but currently he did not intend to actually make any resource control settings.
The administrator was shocked that when under a period of heavy CPU usage, the Sales and Finance VMs appeared to drag excessively, yet VM-1 and VM‑2 continued working normally. Eventually, the problem was traced to the allocation of the CPU Shares. Each VM in the Sales and Finance Pools had obtained a much smaller number of CPU Shares than VM-1 and VM-2.
This resulting total of shares at the cluster level was 10,000 (1000 CPU shares for each of the two VMs and 4,000 CPU shares for each of the two resource pools). This means that each of the resource pools were guaranteed to get at least 40% of the available CPU capacity of the cluster, and each of the two VMs were guaranteed to get 10%. Fifty VMs were placed in each of pools. Each of the VMs placed inside the pools was guaranteed to get 40% divided by 50, which equals 0.8% of the available CPU capacity, while VM-1 and VM-2 were each guaranteed 10%. Another way to view this is that each of the 50 VMs in the Sales pool received 4000 CPU Shares divided by 50 VMs or 80 CPU Shares. (Note: Each of these VMs was configured with one CPU and default CPU Shares, so they shared the pool’s CPU Shares evenly). VM-1 owned 12.5 times as many CPU Shares as each of the Sales VMs. Under contention, the VM-1 was granted 12.5 times the amount of CPU time as the Sales VMs.
If resource pools are used, ensure that each VM is placed in a resource pool and not outside of all resource pools. If nested pools (child pools) are used, then extend the recommendation to the parent pool. For example, if a parent pool named Production contains two child pools named Tier-1 and Tier-2, then do not place any VMs directly in the Production pool; instead, place them in either the Tier-1 or Tier-2 child pool.