There are two situations where running applications directly on the hypervisor might be beneficial though:
- If you have to run multiple untrusted (and possibly malicious) tasks on same host. In this case virtualization provides better isolation/security than just containers or processes (which would be vulnerable to kernel exploits, or other ways of gaining root inside a container allows to take control of the host)
- If the hypervisor is fixed and you can't touch it (i.e. Amazon EC2). In this case running applications directly on the hypervisor might eliminate some of the virtualization overhead.
The attack surface of a VM is rather large, particularly when you consider the dozens of emulated devices and instructions. For example, there was a notable hole in SCSI emulation recently discovered which let any guest overwrite any part of a host's disk (by sending some obscure SCSI commands which weren't being filtered by the virtualized device properly).
Wait, you're saying Google NaCl could be going the way of Java -- being used for server side containers, rather than client side apps? (I don't really see why you'd want that over using a single process(tree)/binary compiled from go...).
[1] https://news.ycombinator.com/item?id=3746222 [2] http://zerovm.org
The programming language runtime is mapped to execute directly on top of the hypervisor.
There are already such systems for Erlang, OCaml, Haskell and Java runtimes.
If the programming language has a good library, there is no need for an operating system, the hardware access can be taken care by the hypervisor.
This leads to safer and faster servers running on virtual machines.
Some kind of microkernel, yes. With the set of required features for hardware abstraction and virtualization, with everything else being provided by the respective language runtime.
This is much faster than traditional operating system stacks, and may provide a way into bringing microkernels into mainstream OSs.
When using programming languages that come with batteries included, meaning with a good set of libraries for all the usual OS services, then removing a few layers between hardware and application helps running everything faster and increases security due to a smaller set of code.
The guys behind Microsoft's Singularity project are also researching something similar for Windows, a project named Drawbridge, where the full OS runs on a hypervisor as a set of libraries in user space.
Anyway this is nothing new, the idea of a virtualized OS goes back to OS/360, it was just kept away in the mainframe world and is now becoming mainstream.
When I was in school, a common formalism for talking about operating system design was that they provided a virtual machine abstraction to each process. As time went on the "devices" looked less and less like actual hardware devices, so instead of having an emulated punchcard reader and emulated interrupts, you'd have a read(2) syscall. But that's a relatively unimportant detail.
And with paravirtualization the cycle continues: the abstraction the guest sees is no longer that of a bare metal machine, but one with an increasing number of syscall-like hypervisor calls...