The top 5 things you could be doing with virtualization but aren't, and how to start

1) Resource Pools


Alot of people make it to the first step of the virtualization project on their own. They download ESX or ESXi, get it on a decent server-class box, they download VMware Converter and P-to-V a bunch of servers, or build and clone a bunch of test servers, and that's when we come in.

Production level virtualization is real, but the number one threat to the stability of the platform is lack of planning.

Resource utilization is usually the first unplanned issue that becomes obvious. Virtual Machines in a cluster are in the Wild West, as far as resource utilization goes, by default. The initial vm creation process does require from the administrator a "limit" for memory, and a number of vCPU's for the vm - 1,2, or 4. But each server also has a default "reservation", usually much lower, and once the host is overcommitted, that is the only amount of memory that the ESX host is providing, if it has to spend the resources elsewhere in a tough economy.

Resource pools are meant to be the law and order in virtual resource management. A parent pool is made up of all the resources in the cluster - all the memory, and all the gigahertz of the cpus times all the cores; but the parent pool is NOT where the virtual machines go. Rather, just like in a physical data center a few years ago, the resources are broken up into different silos, possibly by department, or by purpose within the company. In the physical data center, nobody would expect the backup servers to get up and take resources out of the production web servers across the data center, but by default in a VMware implementation, this could be what's happening.

The box we put ESX on has alot of resources -not infinite, but plentiful. They need to be documented and budgeted. It's like putting a bunch of families in a bunch of homes. You can't just go down the list of family names, and connect them to the list of addresses. If you do, you'd have the family of 9 crammed into the two bedroom apartment, and the single guy who's never home in the castle on the corner, taking all the resources in the neighborhood.


Instead, you'd have to go interview each family a little, find out not just how many members there are, but how much stuff they have, and how often they have how many guests over, or are likely to. You'd have to go see all the addresses on the list; some are nice big homes, some have yards, some have fences around the yards, some are dainty little museums, not appropriate for the big rowdy family.

The SQL or Exchange servers might be that big rowdy family; they ought to go in a back office "resource pool" that have all the resources the servers will realistically require allocated, and set aside from the rest of the data center.

The web servers for internal portals should be given realistic reservations - the minimum resources required on the host to run this vm - as well as realistic limits. They would go in their own, separate pool.

Administration servers might go in a third pool, and so on. Another decision to make on each child pool, is whether or not the pool is "expandable". It is expandable by default.

We deslect that in most cases. When all the resources the web servers could ever realistically need have been set aside in a resource pool, there is no need to leave it "expandable". We don't need to let the servers reach out and take more resources from the parent pool if they feel like it. Most of the back-end, well known and well-planned vm's end up in non-expandable memory pools; the less predictable production servers get the "expandable" check box left checked, so if the administration servers aren't really doing much because it's lunchtime, the public-facing production servers can take advantage of the resources. That puts the law and order into the default wild west.



parts 2,3,4, and 5 coming soon