Close this search box.

These Archived Zombie VMs will Not Come Back to Haunt You

The freedom and flexibility to quickly spin up virtual machines (VMs) sounds great on almost every level except one: the worry that IT administrators experience about idle or zombie VMs coming back to haunt them after they are deleted. It is this apprehension – maybe more so than any other factor that leads IT administrators to retain tens, hundreds or even thousands of zombie VMs long after they should have been removed. By taking advantage of the VM Archiving feature found in CommVault Simpana® 10 Service Pack 3 (SP3), organizations can overcome this natural fear while simultaneously reducing VM sprawl and better utilizing available resources.

Robbie Wright over at CommVault highlights one of VMware’s key benefits: the flexibility to spin up VMs to accommodate short term projects in testing, development and even production environments. It is this use case that led many organizations to first adopt server virtualization with many continuing to leverage VMware in this method today.

Yet this practice has a dark side. Once the testing or development is done, the VM can and should be decommissioned. Yet in a blog entry Wright says, “Most of the VMs created for these use cases never get decommissioned and continue to consume valuable resources long after their useful life has ended.

The resources that zombie VMs can consume are eye-opening. An idle Linux VM may, by default, “wake up” as frequently as 100 times per second. Each of these 100 wake-ups consumes processor time and precludes the Linux Guest VM from ever truly becoming idle.

On the Windows side, some argue that there is no such thing as a truly “idle” Guest Windows VM. While CPU utilization numbers vary as to exactly how much CPU an idle Windows VM consumes, some users report as much as 100% CPU utilization on allegedly zombie VMs that should be consuming no CPU cycles.

The amount of storage capacity wasted can also be substantial. The recommended minimum partition size for the Windows Server 2008 and 2012 operating systems is 66 GBs. While Linux operating systems need far less for their operating system installs (generally under 10 GBs,) having tens or hundreds of idle VMs with allocated storage capacity to host their operating system and application data can easily result in tens if not hundreds of TBs of storage capacity being allocated but wasted and sitting idle.

This waste prompts some organizations to act. Yet when an organization takes the initiative to identify idle or unused VMs so it can reclaim these resources, who realistically has the time to thoroughly investigate and verify whether or not a VM is truly “idle“? Even should such a determination be made, who will then take responsibility for pushing the “Delete” button? 

Conclusively determining whether or not a VM is “idle” can take hours, days or even weeks. Then once it comes time to actually push the “Delete” button arrives, every IT administrator gets a little nervous. After all, who really wants to explain to someone (likely quite angry) why you have just deleted their data?

This is where CommVault Simpana’s VM Archiving enters the picture. It eliminates the need for IT administrators to research and identify which VMs are sitting idle and can potentially be deleted. Rather they can set policies within CommVault Simpana that identify the VMs that are generating little or no activity over a defined period of time (days, weeks, months, etc.) as well as help organizations spot those VMs that are generating activity when none should be occurring.

Once a list of potential zombie VMs has been created, CommVault Simpana addresses the intangible but very real concern that every IT administrator has about pressing the dreaded “Delete” button. CommVault Simpana 10 leverages Storage vMotion to move the idle VM off to a lower cost tier of disk (though it can also place the VM on tape or in the cloud.)

Once the VM has been moved, Simpana leaves behind a stub on the production storage.  In this way should a VM be unexpectedly needed again, the stub file may be used to recall and recover the VM from the archive. This recovery can occur through an ESXi management console, the vSphere vCenter management interface or an automated workflow set up within CommVault Simpana so the VM recovery occurs without IT administrator intervention.

Removing zombie VMs from production IT environments should be a part of every organization’s best practices for optimizing the management of their ever more virtual data centers. However the process of identifying and then removing these VMs from production needs to be as automated and stress-free as possible. Using the VM Archiving features found in CommVault Simpana 10 SP3, organizations get the automation and optimization features they need to confidently put their zombie VMs to rest without worrying if that decision to archive these VMs will ever come back to haunt them.


Click Here to Signup for the DCIG Newsletter!


DCIG Newsletter Signup

Thank you for your interest in DCIG research and analysis.

Please sign up for the free DCIG Newsletter to have new analysis delivered to your inbox each week.