Anyone who has virtualized the server environment understands the enormous amount of flexibility delivered via virtualization. Common tasks such as deploying a server for a new application or creating an entire multiserver development environment to test a new software package take a fraction of the time that they would with a physical environment. Better yet, doing so appears to be nearly free: no purchase orders for new hardware, no waiting for shipment, and no hunting for rack space.
However, with great power comes great responsibility. All too often, the agility blessings of virtualization become a curse as the number of virtual machines spirals out of control. If left unchecked, this VM sprawl can have serious security and licensing consequences -- not to mention sapping precious (and expensive) storage resources.
Unsurprisingly, a wide array of management products have been developed to tackle the VM lifecycle management challenge. However, if you're a relatively small shop, spending money on a niche management tool (and having the time to use it fully) may not be in the cards. If you find yourself in that boat, heer are five simple rules of thumb that should help.
Rule No. 1: VMs are not free
Despite the fact that you can create them in the blink of an eye, a virtual machine is by no means free. The incremental cost of consuming a slice of compute and storage resources is relatively straightforward to determine, but that's not the only consideration. Beyond that, the software licensing for the operating system itself and other tools such as antivirus packages are factors, as does the cost of protecting that VM. Not only are you chewing up primary storage, but you'll also need to plan for capacity on your backup systems.
Some quick work in Excel should let you build a reasonably accurate cost model that you can use to communicate the cost of creating large numbers of VMs to your stakeholders. If the cat is out of the bag and your users know you can create machines for them at a moment's notice, this kind of cost visibility may be your only way of convincing them that fast and easy do not mean free.
Rule No. 2: Nothing is temporary
Where I've seen serious VM sprawl in the wild, the culprit is almost always related to test and development environments. Because virtualization makes it relatively easy to create live clones of an entire application environment, it's common to see those clones used to test upgrades or train users on an upcoming version upgrade.
I've often seen the "it's just temporary" excuse used to justify not purchasing licensing or planning backups for these kinds of systems. In some cases, that "don't worry about it" approach might be fine and, depending on the software in operation, even legal.
However, more often than not, these systems aren't just temporary. I've seen systems that were cloned for a planned two-week period still hanging around years later -- just as unlicensed and unprotected as they were the day they were cloned. The reasons vary, but the bottom line is that it is far, far easier in practice to create something than it is to delete it. The lesson here is to avoid deploying any VM unless you've planned for it to be permanent -- because it usually will be.