Taking Control of VM Sprawl (Part 2)

By /

In my previous article in this series, I talked about some of the reasons why VM sprawl needs to be taken seriously. VM sprawl is more than just an annoyance. There is actually a tangible cost associated with every virtual machine that is created, and those costs can quickly add up as an organization accumulates more and more virtual machines. So with that said, let’s talk about some ways of coping with VM sprawl.

Like most things in IT, VM sprawl must be dealt with in a planned and methodical way. If you just begin deleting virtual machines then you are most likely going to cause problems. Almost as importantly, simply deleting virtual machines does not really deal with the problem as a whole. You might have cleaned things up a bit (if you haven’t caused problems in the process), but you haven’t done anything to keep VM sprawl from happening again. What you have done is slapped a band aid onto the problem and implemented a temporary fix (if you even want to call it that).

So the first thing that we have to do is to come up with a long term plan for dealing with VM sprawl. In doing so, there are two bits of advice that I would like to give you up front.

The first thing that you should consider is that addressing VM sprawl is about more than just purging unwanted VMs. Merely purging unwanted VMs implies that the problem is only about dealing with clutter. In reality, addressing VM sprawl is about reclaiming resources such as storage, software licenses, and that sort of thing. If you approach VM sprawl with this philosophy in mind then VM sprawl can be treated as a business problem rather than being treated as spring cleaning. So why is this important? Well, remember that IT’s job is to use technology to help the organization achieve its business objectives. When VM sprawl is treated as a business problem, dealing with it becomes a priority and ceases to be one of those things that somebody will deal with one day when they have time.

The other bit of advice that I would give you for taking care of VM sprawl is to take a two pronged approach. First, you must clean up the existing VM sprawl. Second, you must take steps to prevent VM sprawl from happening again. Otherwise your cleanup efforts will yield only temporary results.

Cleaning Up Existing VM Sprawl

So now that I’ve gotten the philosophical stuff out of the way, let’s talk about cleaning up VM sprawl. Cleaning up existing VM sprawl involves three main steps:

  • Identifying VMs that are no longer needed
  • Removing the unwanted VMs
  • Removing VM components that might be left behind

I am going to spend quite a bit of time talking about those first two points, but before I do I want to take a moment and clarify what I mean by removing VM components that might be left behind.

Depending on what hypervisor you are using and how your VMs are configured, deleting a virtual machine does not necessarily mean that the corresponding virtual hard disks will be deleted. If dealing with VM sprawl is truly about resource reclamation then it is important to make sure that virtual hard drives get deleted along with the corresponding virtual machines.

Identifying VMs that are no Longer Needed

Figuring out which VMs to delete is probably the most difficult part of the entire process. I have known people who shut down suspect VMs and “wait to see who screams”. Sometimes that might be the only way to determine whether or not a VM is still being used, but I recommend using that method as a last resort because the method carries the potential to disrupt business processes.

The first step in determining which VMs can be safely deleted is to compile an inventory of all of the existing VMs. As simple as this first step might be however, it comes with a huge gotcha. Depending on the size of your organization there will probably be new virtual machines created before you even finish inventorying the existing VMs. That being the case, you are going to have to get anyone else who is authorized to create VMs to agree to give you information about any newly created VMs. It’s also a good idea to put some sort of reporting mechanism into place so that if someone does create a new VM without telling you then you can at least be made aware of the new VM and can follow up with whoever created it.

Once you finish creating the VM inventory, the next step is to figure out which VMs can be safely removed. This is by far the most difficult step in the entire process.

In all likelihood, there will probably be a few VMs that you can immediately identify as being safe for removal. Even so, I recommend that you avoid the temptation to delete those VMs. There are a couple of things that you should do first.

The first thing that you should do is to shut down the VM (to prevent further write operations) and then make a backup. If you happen to be wrong about the VM being unnecessary then you will want to have a way of restoring the VM.

The other thing that you should do is to get someone to sign off on the VM removal. Those of you who know me know that I am not a fan of bureaucracy. I like to keep things as simple as I possibly can and bureaucracy often gets in the way of that. At the same time however, I am also a big believer in self-preservation. Removing a VM without involving anyone else could land you in the unemployment line if it is later determined that the VM was needed after all.

Remember earlier when I said that you need to put in place a method for keeping VM sprawl from recurring? Well, this is where you start. I recommend creating a form (paper or electronic) for each VM. I will talk about what all to include on this form later in the series, but one of the things that I recommend listing is the VM owner. This is the person who created, requested, or is ultimately responsible for the VM. Before you delete a VM, the VM owner needs to sign off on the VM removal (at least for now, I will talk about automating the process later on).

So what about those VMs that you have identified for removal? It’s a bad idea from a self-preservation standpoint to authorize the removal yourself, even if you have the authority to do so. Have someone else to sign off on the removal. If the VMs have no real owner then you might consider having your boss to sign off on the VM removal. If your boss asks questions, explain that it is a part of process that is being put in place to control VM sprawl.

Conclusion

As previously mentioned, the toughest part of inventorying VMs is determining the status of VMs for which you have no direct knowledge. In Part 3 of this series I will discuss some strategies for gathering information on these types of VMs.

If you would like to read the other parts in this article series please go to:

About The Author

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at: www.brienposey.com.

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top