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.
Rule No. 3: Track ownership
When new systems are created, it's very important to define who requested their creation and who is ultimately responsible for their existence. By designating a single contact -- maybe the analyst for the application the system runs or the head of the department it serves -- as the prime decision maker for every VM, you make it that much easier to determine when the use of the system transitions from different production states, such as development, test, production, sunset, and decommission. Without that contact, years later you may not know where to go to get an authoritative answer on whether the system needs to be backed up or can be decommissioned.
Rule No. 4: Develop a naming convention and stick to it
As you grow your virtualization environment, pay close attention to how you name and categorize your VMs. If you're managing only 10 or 20 VMs now, it may be easy to keep track of them, but a few years down the road when you have 40 or 50, it will not be. Even if you can keep it straight in your head, others you work with (or might hire later) won't have a clue what they're looking at if you don't have a solid naming convention.
If you're a VMware vSphere user, don't forget to take advantage of the custom fields in vCenter to make it easier to track information about your VMs. I've seen everything from purpose, user point of contact, creation date, expected retire date, backup methodology/schedule, and even vendor support information successfully tracked this way.