Something I encounter frequently in the field is the use of Resource Pools as nothing more than organizational containers. This is not a good idea as this can have many implications on your VM utilization and performance. As a best practice, you should use the folders feature in the "VMs and Templates" inventory view for organizing your VMs into logical groups. Administrators typically do this because they default to the "Hosts and Clusters" inventory view.
Frank Dennemen, among others, has a really good explanation on the impact of using Resource Pools as organizational containers. Frank goes on to explain that simultaneous vMotions are restricted under certain Resource Pool configurations, which is also documented in KB 1026102 but I noted that the KB is related to vSphere 4.x only.
Indeed, testing this out in a vSphere 4 lab I find that if I have a VM migrating from one server to another AND changing Resource Pools in the same cluster my vMotion migrations are serial (note one active and the other waiting).
However, if I perform another vMotion without changing Resource Pools, they are allowed to progress simultaneously.
So, does this limitation still apply with vSphere 5? It would appear not, but I haven't found any official statement to that effect. I did conduct an experiment with vSphere 5 in the lab and found that I was able to vMotion two VMs simultaneously under the conditions stated in the links above.
I created a three node cluster and three Resource Pools. I then placed one VM each in two of the resource pools and on two of the ESXi hosts.
From there, I kicked off a vMotion of both VMs, selecting the third host AND designating the third Resource Pool as the target. As you can see, the vMotion requests are both actively running and they eventually completed.
Other iterations mixing moves between two different Resource Pools as well as to a host external to the cluster all allowed simultaneous vMotions.
I still do not recommend using Resource Pools as folders in vSphere 5. But at least you can now employ Resource Pools without concern over this particular limitation.
If you do use Resource Pools, you should leave unreserved CPU for overhead (10% for clusters and 30% for hosts). See the vSphere 5 vMotion Performance Best Practices Guide for more info.
I'm one who has, in the past, used RPs for organization and delegation of authority. In those cases, I would not set reservations or shares, thinking that would avoid performance and contention problems. But I've read more and more that this is not recommended. So do you recommend using folders in the "VMs and Templates" view for delegation?ReplyDelete
I think everyone has been guilty of this because we tend to default to the Hosts and Clusters view for day to day administration.
Except VDP organizes backup groups by resource pools.ReplyDelete
To be honest, I've never looked into VDP but I will. It does make sense to organize backups by resource pool if they are used to promote critical workloads, you would want to make sure those VMs got priority for backup. Again, not sure but I will look at this. Thanks!Delete