VMware Cloud Community
maishsk
Expert
Expert

So how long will you keep your VM's??

There has been something that has been bothering me for quite a while, I have looked for discussion on this on the web, asked my peers, professional consultants, but have not yet received a satisfactory reply. Everyone keeps on saying, "Hmm.... that is something we need to think about" or "We haven't yet reached that stage so we haven't given it much thought"

Let me throw it here in the group.

We all know that Virtualization is the next best thing since bread and butter. It is a good technology. It is evolving at a huge rate, and is definitely here to stay.

Part of the virtualization game is to P2V old hardware for a number of reasons...

a. expired hardware warranty

b. no more application support

c. applications tied to specific hardware (NIC's etc.)

OK so we all do this, we convert a physical server to VM, and all is hunky-dory.Old hardware gets retired.

Fast forward 3-6 years. Our ESX hosts have been replaced once twice maybe even 3 times over that period. Faster CPU's, more and faster NIC's, more HBA's, more RAM - the whole 9 yards. And because we managed (thanks to VMware) to do this without minimal if any downtime to the VM's itself, we all got a huge raise!!! :smileydevil:

But by now have a hundreds of Windows 2003 Servers, a multiple amount of windows 2000 servers and maybe heaven forbid even some windows NT4 here and there.

If we were to stay with physical servers then the server hardware (and its applications) would have an end-of-life (depending on the hardware I would personally not go for more than 5 years per server - ith hadware maintenance contracts). Now we are virtualizing anything what would be the incentive for an application owner to upgrade their OS and their applications. Before you could say, "We need to retire the server, so a full re-install, migration of the applications and the whole she-bang..." but now the hardware is no longer part of the equation..

I will go even further to say Iifecycle manager is not making it any easier. So you start as Dev. Then staging, then test, then beta. From what I understand about the product, this can all be done based on the original VM. So say the above process takes anything from 6 months to 2 years? then you go production. with a server that has been up and running for 2 years already. If we were talking about physical servers then at least the servers would have been built from scratch before going live. I am not saying that it should not be the same with VM's, but I think that you can all see the problems that might arise here.

So here is the "million $ question".

How would you go about setting a policy for the end-of-life for a VM?

Maish

Systems Administrator & Virtualization Architect

Maish Saidel-Keesing • @maishsk • http://technodrone.blogspot.com • VMTN Moderator • vExpert • Co-author of VMware vSphere Design
Reply
0 Kudos
4 Replies
aguacero
Hot Shot
Hot Shot

You raise an interesting question. You would have to look at it from the top layer (Application) down. Exampe, If your VM is running Windows 2003 SP 2 with Exchange 2003 SP 2, then you would have to consider if you are opting to migrate to Windows 2008 and Exchange 2007. This means you building a new VM with the necessary componenets. You will have to keep the same methodology on the Software view as compared to both physical and software combined views. With virtualization, the underlying hardware will continually change with time and most engineers will migrate to that new platform. You can consider these obsolete VM in the same fashion as old e-mails. You can "archive" them to a shared lun for old sake and have policy in place for continually montiroing of such archived VM's. Don't be surprised that VMware releases a new feature which is "archive-driven" policies/application which could start the process of archiving these VMs to a "archive datastore" of some sort. VMware can call it V-Archive Utilization Layer Technology (VAULT). :smileylaugh:

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!

If you found this information useful, please consider awarding points for "Correct" or "Helpful". Thanks!!!
Reply
0 Kudos
jamieorth
Expert
Expert

I would have to say that it would depend on the business requirements. For me in the financial industry, regulations and auditors indicate that even the OS level should be supported, so as the support for the OS goes end of life, so should the application on the OS, forcing an upgrade or change of application. What virtualization allowed was a remediation in the gap between hardware refresh and OS/application refresh. Now, as a part time consultant I have clients that do not adhere to such standards, so when they have an application that runs fine on NT4, then why not keep it around until the business requirements change?

Regards...

Jamie

If you found this information useful, please consider awarding points for "Correct" or "Helpful".

Remember, if it's not one thing, it's your mother...

Reply
0 Kudos
Texiwill
Leadership
Leadership

Hello,

This is an interesting question. I would say apply the same rules you did to the physical world to the virtual world. If the VM needs an upgrade due to some new Compliancy model then retire the old VM in favor of the new, etc. If there is newer software to make things work then the older VM should also be retired. Lifecycle is part of administrators toolbox and should probably be defined during design time.

I would create a retirement datastore so as to retire VMs but NOT delete them outright, you never know when you need the data.. But then again, you will eventually have to delete the VMs from this space as well. Just like you have to consider the length of time your backups last.


Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

--
Edward L. Haletky
vExpert XIV: 2009-2023,
VMTN Community Moderator
vSphere Upgrade Saga: https://www.astroarch.com/blogs
GitHub Repo: https://github.com/Texiwill
Reply
0 Kudos
lreesey-old
Enthusiast
Enthusiast

I would say the question is actually a number of questions depending on your environment. With the exception of the first question, if you don't have these answers for your physical environment you probably wont in your virtual.

1)What and when do you really want to P2V?

2)What is the rention policy for a vm based on the 'stage' it may be in - test/dev/production?

3)How long do you support 'legacy' operating systems?

Remember one of the benefits of virualization is that you don't have to replace all your hardware regularly but if you decide you'd like to you can do so with minimum downtime. That doesn't mean you can't use those points in time as a really good excuse to 'purge' older vms though Smiley Wink

My answers would be:

#1 Use the process of converting from physical to virtual as an opportunity to move the application to a newer OS. Build the vm and allow the developers to migrate the application from old to new. In some cases, that is the only option anyway, so you can always just make in an option for everyone.

#2 This is a tricky one and will probably need management's blessing. Again, depending on the environment you may be stuck with each 'stage' until the application itself is no longer in use. Some environments may allow you to remove a test and/or development vm once the production vm is in place. If you work closely with the different groups you may find a happy ground somewhere in between.

#3 Again, with management's blessing, I would push to only have OS's that are currently supported without paying for it. It is an easy method of purging older systems and keeping things relatively current.

The greatess success I've seen so far in purging/updating older systems is when there is a major change in the environment. New datacenter, change of IPs, new SAN install. Its not a formal policy but when people hear they can have bigger, better, faster they tend to lean that way.

Reply
0 Kudos