Tag: VMware Resource Pools

An assessment revealed that in a company’s current physical environment, the total RAM usage of the Windows servers during times of peak demand was 128 GB, which was 67% of the total RAM capacity of 192 GB. This led to a decision to allow 150% RAM over commitment for the Windows VMs. After analyzing the existing servers and planning for growth for three years, the predicted total configured RAM for all VMs was 450 GB. But, to allow 150% over commitment, only 67% of the estimated, or 300 GB, was procured for direct use by VMs. More RAM was actually purchased to allow overhead and spare capacity for ESXi downtimes, but only 300 GB was planned for direct VM usage.

A company had a hundred traditional, physical, Windows servers in production that they wanted to migrate into a new vSphere environment. They intended to duplicate each production server to create a hundred test virtual servers, each configured identically to its production counterpart, except they would run in an isolated network.

Resource Pools have been great tools to manage resources for large companies where each department was used to buying their own resources but was forced to move to a shared resources model. In this case, each department was accustomed to purchasing their own servers that the IT Department managed. In the new model, all servers were virtualized onto the same hardware, and each department was charged for the CPU, RAM, and other resources they expected to use. The managers of the departments wanted some assurance that they would be provided with the resources for which they paid.

A common issue is where administrators intend to use resource pools strictly for organization and administration. They did not intend to affect the resource usage of the VMs, so each pool is set with default Shares, Reservation, and Limit for both CPU and RAM. The administrator utilizes the pool for administration purposes, such as to configure permissions and alarms, but the pools are not used to configure resource settings. This results in each pool having the same Shares for CPU and Memory, but if one pool contains twice the number of VMs than another pool, then each VM in the first pool is effectively guaranteed only 50% of the amount of CPU and RAM that is guaranteed to VMs in the second pool.

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. 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 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.