Server virtualization is an accepted and mainstream technology used by increasing number of software testers today. The technology helps testers rapidly create virtual machine test environments. Testers who are new to virtualization rely on basic hypervisor technologies from VMware (e.g., VMware Server), Microsoft (e.g., Virtual PC) etc. to create these virtual machine test environments. One of the downsides of using a bare hypervisor is the problem of introducing Virtual Machine (VM) sprawl. A detailed post on the downsides of relying only on a basic hypervisor are discussed here.
The Problem of VM Sprawl: Virtualization technology makes it extremely easy for end users to create and deploy VMs. This can quickly get out of hand – resulting in an increasing number of VMs and difficulty in tracking and managing the VMs. This problem is referred to as VM sprawl. Most often, VM sprawl issues have a profound impact when VMs are used in production (and this is discussed often). However, it is an equally important problem to be aware of when you are actively using virtual machines in your dev/test environments.
When is your Dev/Test Organization at Risk with This VM Sprawl Problem: Here are typical scenarios that are would quickly lead to a VM sprawl problem in your organization.
- Your organization or group lacks clear policies to control the creation and deployment of VMs in your environment
- When VMs are abundantly used by your dev/test teams (e.g., it is the de-facto choice when users need new machines. And everyone operates with their own instance of VMware Server/MS Virtual PC etc.)
- The risk of being affected with the VM sprawl problem are higher if your organization is running distributed teams (offshore/distributed company locations)
Why is the VM sprawl problem relevant to the Dev/Test Organization: So, if you do think that your organization is at risk, what are the specific problems that you are likely to run into if you let things continue ‘as-is’ and without addressing the VM sprawl problem?
- Resource hogging: It is likely that some of your dev/test staff would let their VMs run continuously on server resources – sometimes without keeping a track of when it is being actually used or left idle. This will lead to server resources being blocked and being unavailable for others to use.
- Increase in operational costs: Since every user creates and runs their own VMs, the cost of storage, server resources required etc. will go up linearly.
- Difficult to track license usage: It will be practically impossible for IT administrators to keep track of specific software/OS licenses being used in each VM
- Compliance and audit: This is less of a problem in dev/test, but a problem regardless. If your administrator ever needs to respond to a compliance audit, it will be a nightmare tracking and reporting the inventory of all machines being run
- Impossible to track VM creations: It will be quickly impossible to manually (via Microsoft Excel, Word etc.) track VM creations by individuals as well as the resource utilization by each user
If VM sprawl is a problem that you are seeing in your dev/test environments or is likely to be a problem that you will run into shortly, you should consider looking at lab management solutions like VMLogix LabManager. These solutions do a good job of herding the VMs created in a lab (dev/test) environment and provide powerful tools to manage these configurations.
My next post will talk about how VMLogix LabManager can help control your VM sprawl in the dev/test environments. Stay tuned.
- Srihari Palangala
Other useful reading: