Getting under the shell of virtualization

What’s an operating system anyway? The questions we posed this week were quite disconnected, but they inspired similar perspectives from the comments. Not least, respondents to the first article sought to address what exactly was an operating system. One respondent summed it up perhaps, by saying:

The answer really is “everything that doesn’t do application-level processing”. It’s a pretty vague question, and appropriately enough gets a vague answer.

He was more specific on what might constitute the core of the operating system that might be called its ’kernel’:

That’s a very specific question, with a specific answer: the section of code which directly controls activation and deactivation of all other sections of code.

What relevance does this have to virtualization? It’s an important distinction when we start to think about what exactly should go into a hypervisor, and where it should sit. TooMuchCoffee answered the former point quite succinctly when he said, “When is an operating system not an operating system? When it’s a big ol’ bag of drivers.”

Of course it’s not just about what vendors/communities come up with, but also what organizations adopt, and we should note that it is too early to fully grasp where things are going in terms of hypervisors, virtualization and so on. In the article we noted that leaner versions of both Linux and Windows Server were already coming on-stream. Competitive pressures would suggest this trend will continue, to the extent that we may well end up with what are to all intents and purposes microkernels. Not a moment too soon, said another respondent:

The world and his dog has been crying out for a decent microkernel OS, but no-one has ever been willing to put the time in, instead developing more and more convoluted ways to patch, modify and blu-tack external code onto the major monolithic kernels.

However this is by no means a done deal, and in today’s legacy-rich environment it may well be a step too far, as indeed might the other architectural models that can be dreamed up. That hasn’t stopped the speculation in the comments however. One anonymous respondent suggested running a JVM on top of Xen, or indeed WINE (a controversial open source Windows compatibility layer) on Xen:

Windows applications could be run without the need to have an instance of Windows. Similarly other OSes could be made redundant with similar technology.

If we started from scratch, how different things might be! However, given that we cannot, backwards compatibility remains a major reason why we need to stick with what we have:

Until application programmers can target the Virtual Machine environment through a standard API then the OS is here to stay.

All the same, comments such as these are a good illustration that there should be no sacred cows when it comes to virtualization. To bring things full circle and link back to the “what’s an operating system” question, I’d like to finish with some thoughts on the second article, from W. Hower. First concerning the hypervisor layer itself.

I’m very much of the opinion that the basics of running a virtual machine should absolutely be free. The notion of paying for a hypervisor is simply ludicrous. There’s nothing to it.

Now, while this view may be a little simplistic (I’d like to hear what OS kernel and hypervisor developers think of this sweeping statement), what it does illustrate is the pervading view that the very heart of a computer is rapidly commoditising. If this is the case, we will likely continue to see more attention turning to the operational aspects, as continues Mr Hower:

Management is another matter, as some of the pioneers of this latest wave of virtualization seem to have recognised some years ago, if you can integrate the management of these virtual platforms and environments into a broader suite of solutions it’s real value add – hence it becomes a chargeable effort, and something that I’m prepared to pay for.

Well sir, rest assured that this perspective is shared by all major virtualization vendors. Whatever happens inside the box, it is what we do with it (and how) that will deliver the most value.