Resource pools are a very useful tool, they allow you to create pools of resources on a cluster using that cluster’s CPU and memory. Then you are able to create VMs on those resource pools and those resource pools will only provide the resources they are limited to to those VMs you can even put resource pools inside of resource pools. The main reason you would create resource pools on a host or cluster would be so you could provide a certain amount of CPU or RAM to a certain team, say sales, and allow them to create VMs and work within their own resource pool separate from HR. Similar to what I discussed in my NIOC post resource pools also employ the use of shares, reservation, and limit. Shares are most useful if the VMs or resource pools are on the same cluster, or resource pool, competing for resources. The higher the level of shares you give a VM or resource pool, the more resources will be allocated relative to another VM or resource pool with lower shares during times of contention. Reservation is the minimum amount of CPU or memory a resource pool, or VM, will have allocated to it, say you configure a resource pool with 100 GB of memory and a reservation of 60, you are not guaranteed to get the full 100 GB of memory but your resource pool will always have 60 GB of RAM to provide to VMs under its control. Finally there is the limit, the limit is almost the opposite of the reservation, it is the maximum amount of CPU or memory a resource pool, or VM, is allowed to have, some resource pools or VMs may not need to exceed 10 GHz of CPU, so a limit is set and it can’t exceed that. Two important things to note are if you are going to configure resource pools on your cluster you must enable DRS, distributed resource scheduler, which I touches up on another post. Another thing to note is that when you create a VM, the memory and CPU you assign to it are its effective limits.