Problem solve Get help with specific problems with your technologies, process and projects.

Mommy, where does VM sprawl come from?

VM sprawl creeps up on a data center. Before you can tackle the issue, it helps to understand how VM sprawl occurs and what it can do to an IT shop.

VM sprawl doesn’t just show up one day. It develops slowly over time, often a result of poor management practices and a lack of control over virtual machine provisioning. A central benefit of virtualization is how quickly and easily you can deploy new instances of Windows and other operating systems. Many businesses have slashed the time it takes to commission a new server from weeks to days or even hours. But this efficiency has caught many companies off guard.

More on VM sprawl

Control VM sprawl in your virtual server infrastructure

Closing the VM sprawl floodgates

Virtualization challenges: Security, storage and VM sprawl

The term “VM sprawl” is generally used to describe the unchecked creation of new virtual machines (VMs). If not restrained, it can sap your data center of precious resources that could be allocated to genuine production virtual machines. The VMs that are created for a short-term project are still using CPU, RAM and network resources, and they consume storage even if they are powered off. In the longer term, VM sprawl could lead to a computing environment running out of resources at a much quicker-than-expected rate, and it could skew wider capacity-planning exercises.

Before an organization can eliminate unnecessary VMs to reclaim resources, IT personnel must determine if VM sprawl exists in their data center.

Identifying VM sprawl
VM sprawl creeps up on many organizations. You may have it and not even know it. There are a few sources of VM sprawl. First, there is unrestrained growth of VMs used for development purposes. These machines are meant to be merely temporary residents in your virtual infrastructure. But they can be like the cockroaches of virtualization; they spread like wildfire and are difficult to get rid of. Folks often refer to these as “zombie VMs” because they hang around in a ghostly fashion, consuming valuable resources even if users aren’t connected to them.

Second, there are “legacy” VMs, which in most cases came into the environment from the physical-to-virtual (P2V) migration. Companies often have no idea what these VMs do or who uses them and at what frequency. We found that such machines were never used and had no clear role in the current environment. They were often maintained only because the business didn’t know the possible effect of decommissioning them.

In many respects, this is similar to the initial capacity-planning assessments carried out before embarking on a virtualization project. Those assessments found servers that had not been used for months, sometimes even years. This demonstrates that sprawl is an ongoing management problem—not some new phenomenon created by virtualization. Even so, it is fair to say that virtualization has exacerbated an existing challenge.

Third, companies are spinning up new virtual machines to evaluate new software in the proof-of-concept stage. These VMs tend to outstay their welcome. In one notable case, a customer had chosen a competing product but had maintained the proof-of-concept machines that were no longer needed. Such VMs should be used only for the testing and evaluation phase, especially if an organization ultimately selects a different vendor.

To get an idea of the size of a customer’s virtualization implementation, I often ask the following questions:

  1. How many hosts do you have running VMware ESX, Microsoft Hyper-V or Citrix Systems’ XenServer?
  2. How many virtual machines do you have?/
  3. How many of these VMs are used for testing and development?
  4. How many are Windows NT 4.0 or Windows 2000 VMs?
  5. What is the ratio of new VMs that were created to those generated by the P2V process?

The answers to these questions are usually something like “Not sure,” “Lots” or “Let me check our spreadsheet.” Sadly, this lack of insight into a virtual environment is typical and stems from an inadequate audit trail. When I used to ask customers about their physical environments prior to virtualizing, I got similar answers. But it should be easier to conduct a virtual audit because the management systems can be queried using tools such as PowerShell to generate reports. That’s decidedly easier than heading into a data center or server room with a clipboard and pen.

The bottom line is that if you don’t know what you’ve got in your environment, you have no way to decide what should and should not be there. That’s where developing effective VM tracking processes becomes critical.

In the next installment of this VM sprawl handbook, you’ll learn the best ways to control VM sprawl.

Dig Deeper on P2V, V2V and V2P migration

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.