In short, lacking a natural server life span, how vigilant should we be in keeping up with large-scale OS upgrades? Essentially, that's up to the OS vendors themselves. Unless you're willing to run with significant security risks, you're essentially forced to toss that stalwart VM in favor of a new one, though there's no functional reason to do so. If you have a perfectly functional refrigerator, do you go buy a new one just because the manufacturer no longer makes that model? Probably not.
What of that upgrade path? As we learned with physical servers, it's generally best to start from scratch. However, mainstream Linux distributions are perfectly capable of solid upgrades in situ. That fact, coupled with the ability to snapshot the current state before the attempted upgrade, makes a live upgrade a fairly safe bet -- at worst, it will cost your time if a failure occurs. Windows is not as well suited to this method, but it's still possible, and the backup plan of rolling back the snapshot is especially compelling in this instance.
Damned if you do
But as we know, the more you upgrade an OS on the same server instance (presuming that an upgrade is even supported), the crustier that instance gets. Odd things can happen. Errors in future updates due to orphaned packages or ancient changes will start to occur. Future application installations or upgrades may become problematic due to the vagaries of upgrading the instance from an OS released five or even eight years ago.
In short, upgrading becomes more of a gamble than just leaving things alone. In a time where IT budgets are lean and staffs are perpetually shorthanded, the planning and execution of a fresh install and service migration for all of these VMs becomes a Herculean task. In many cases, there they sit, running perfectly, functioning without issue, yet orphaned.
Clearly there are different levels of concern in these instances. Public-facing servers need more attention than purely internal boxes, but the latter should not be completely neglected. If you have an internal Linux VM instance that runs a handful of Web applications, security updates to fix BIND problems aren't a big concern. But if you run a public DNS server and a significant security issue rears its head, you better have those bases covered.
Otherwise, it comes down to budget and vigilance. If the budget for both time and licensing exists to maintain a strict upgrade regimen, then there will be plenty of wasted effort, but the VMs will be fresh. If the budget isn't there -- a more likely scenario -- then you may find yourself watching over a bunch of eternal servers.
This story, "The long life and slow death of the virtual server," was originally published at InfoWorld.com. Read more of Paul Venezia's The Deep End blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.