Unintended consequences of virtualization?

  by Andy Ormsby | 02 May 2007 | Permalink | Featured, IT Management, Software

Earlier this year, I worked with some of our customers on the DST (daylight savings time) problem. In case you are lucky enough not to have heard about the DST issue, here’s a quick explanation: The US has brought forward the start of DST to the second Sunday of March (the 11th in 2007) and is postponing the end of DST to the first Sunday of November. Any computer systems which depend on computing local time in an affected region needed to be patched in order to recognise the change. In most cases, it is the operating system (Windows, Solaris, Linux, etc) that does the work, so it is the operating system that has to be patched. Applications and middleware generally rely on the operating system to tell them what the local time is (if they need it) and so typically do not need to be modified.

Java is an exception to the rule. Java does its own timezone calculations and has its own DST rules, so Java VMs also need patching if they are to calculate the time correctly. But patching Java turns out to be more of a challenge than you might at first think. Unlike operating systems, where it is reasonable to assume that there is one operating system instance per server, there is a lot of Java out there. In the estates we looked at, it was not uncommon to find 10 or 12 copies of Java per server.

Given the number of servers in the environment, typically many thousands for the customers we deal with, the result is a significant amount of work. But volume is not the only problem: Many of these Java installations are not being used – but finding out which ones are unused and can be deleted is distinctly problematic.

How have all these Java instances accumulated? Some will have shipped with other products: one of the ways in which software vendors attempt to exercise more control over the runtime environment is to ship it with the Java version that it has been tested with. Other installs relate to custom software, in which case there is a high likelihood that Java versions have been dropped on the server as released but that there is no defined process for removing them when no longer used. Whatever the reasons, the result is a mess.

Why is this interesting?

I suspect that looking after operating systems is going to become much more like looking after Java instances. Instead of one OS per server, there may be many, hosted using a virtualization layer such as VMWare and Xen. Patching the active ones will be the easy part. But what about a virtual machine that is only used for a batch process that runs once per month. Or inactive DR virtual machines which start only when the primary VM fails? Which ones need patching? (And how do you tell without firing them up?)

Interestingly enough. just as software vendors ship Java with their products to protect themselves from the variability of the environment, the same thing is starting to happen with VMware: take a look at the virtual appliance marketplace on VMware’s website to see some examples of this. If this becomes a trend, we could end up with each product running in its own virtual machine.

Prediction: management of (virtual) servers is going to be a big challenge.