VM lifecycle management: Beware the immortal VM

When it comes to VM lifecycle management, immortality isn't all it's cracked up to be. Sometimes it's best to put ancient VMs out of their misery.

Should a computer be immortal? Like human immortality, it sounds all right until you look at the details. Physical...

computers certainly aren't immortal; anything with moving parts will wear and decay until it ceases to function. But virtual machines (VMs) are just files, so as long as the files are around, so is the VM. Without proper VM lifecycle management, organizations can end up with out-of-date, seemingly immortal VMs.

In the past, operating system (OS) upgrades were tied to hardware replacement. When the risk of hardware failure got too high, IT bought a new computer and installed a new OS. The new OS was necessary, because hardware vendors only release drivers for recent OSes when they release new hardware. New OSes often also meant new application versions, so applications were frequently updated or replaced.

VMs have disrupted this natural cycle. Now, the hypervisor is what's updated, but the VM continues to operate with no awareness that it is on new physical hardware. We are no longer upgrading our OSes and applications every few years as the physical hardware ages. As a result, the VM OS and applications are immortal. I recently came across a critical application running on Windows NT 4.0 -- a 17-year-old OS.

How did this machine remain in use? Surely somewhere along the way it crossed a threshold where it should have been replaced. But because there was no hardware replacement crisis, it just kept running. The VM continued to do its job as it always had, so there was no pressing reason to upgrade or replace it.

Why immortal VMs should be put to rest

However, consider how this affects support costs. In years past, most computers in an organization ran either the most recent version of an OS or the previous version. Now we have VMs running four or five different major releases. It is unlikely that you will find corporate antivirus, security, asset management or monitoring tools that span all these versions -- not to the mention staff with the skills to support multiple OSes. Many IT professionals were still in school 15 years ago when Windows NT 4.0 was the standard. How will they cope when called on to support these IT dinosaurs?

Clearly this isn't desirable or cost-effective, and immortal VMs may become the support nightmare that COBOL was when Y2K rolled around. Corporate IT departments may find that they need the services of the gray-bearded old-timer who remembers when these old systems were new.

So how will corporate IT avoid the nightmare of immortal VMs? I see two possible strategies for VM lifecycle management:

  1. Strong governance to prevent immortality. If the IT department can enforce a VM lifecycle management policy of only allowing a set number of OS versions in the data center, then as new OS versions are released, the older VMs will need to be upgraded. The hard part is that the business unit using the application must usually pay for the upgrade and possibly will have to find a new application the new OS supports. This business unit must pay the cost, but often gains nothing from the upgrade. This will cause resentment of IT. Support cost for central IT will be minimized, but the cost to the business may be high.
  2. Embrace immortality. Step off the upgrade hamster wheel and embrace older OSes and applications. Build a culture of education where younger IT staff members are trained on older systems by those who put them in. Older tools still do what they always did. If that is still what the business needs, then why upgrade? Focus the resources and spending on upgrades in the areas where the business requirements are not being met. Spend less time and money on upgrading and patching and more on adding business value.

Virtualization has disrupted many areas of IT. The OS upgrade cycle is one of many where IT must now make conscious decisions that never existed before virtualization. A clear VM lifecycle management strategy with real IT commitment will prevent a support problem with immortal VMs.

This was last published in January 2013

Dig Deeper on Virtual machine provisioning and configuration

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How do you approach VM lifecycle management?
Cancel
Hmmm. Did no one read or comment on VM lifecycles?

Personally, it's usually my mission when I come into a new organization to seek out the VM Admin (if it's not me) and the SAN guy.  Then we start checking VMs for who and when someone last logged on, created a list that spanned VMs from 3 months to over 3 years. We would then submit this to the IT director for approval or deletion. Of course he's never who has what.  It would be great for AD integrated virtual environment if VMware would include a DATE the VM was built, by which username AND requiring them to enter a short description. However, you get most all cleaned away and then there's two or three left, so you send a department email.  There's no response of course so what do you do?  Hmm? TURN IT OFF and what to see who screams
Cancel
By using vendor support lifecycle and suggesting that the VMs are not forever to bussines
Cancel
Looking for a tool to manage the VM lifecycle and sprawl management
Cancel
Keep the machines operational until the program/application has been updated to allow us to move ahead
Cancel

-ADS BY GOOGLE

SearchVMware

SearchWindowsServer

SearchCloudComputing

SearchVirtualDesktop

SearchDataCenter

Close