Guest post by ACM Queue posted an article titled “Unikernels: Rise of the Virtual Library Operating System“, written by the main developers of MirageOS. The article is a good overview of the motivation and design of Mirage, which is a specialized lightweight hypervisor guest operating system for Xen. It’s developed in OCaml and benefits from its features like memory safety, module system and compiler optimisations. It’s comparable to OSv on many fronts.
More here.
This has been an area of constant research, the area of sandboxing and virtualization is an interesting topic right now given the resource constraints of our new mobile overlords.
The awesome thing is that you can do some pretty cool things today using things like LXC on Linux (messed around with Docker, pretty cool).
In Microsoft land theres Drawbridge OS from MSR and AppContainers in Windows 8.
I think the idea has legs, but I wonder the issues that would arise from the traditional need for software processes to communicate. How is this handled in an isolated libOS environment?
Its brokered in Windows 8, but it comes with obvious restrictions.
In theory, you don’t have multiple processes; you have one process per. VM with a common address space. So you have threads, at best.
I’m not sure if it answers your question about IPC, but the trend I see in a VM world is to use network stack for it. As in: enclose multiple VMs in a separate network space and use a gateway VM to access service(s) that internal/virtual network provides.
So my quick skim of the synopsis suggests that this is something like Linux vDSO’s taken to the extreme, or Exo-Kernels.
I can’t deny this is the way that light-weight virtualization (I.e. SaaS) is going. It’s going to be interesting to see how things go.
Hi,
I’ll tell you exactly how things will go. To start with the “virtual device abstractions” will be made cleaner, easier and leaner. For example, rather than bothering to emulate a real network card (and all its messy details) you’d just have a “hypervisor call” to send and receive packets. The communication between the individual “SaaS guest OSs” will also improve.
Then someone smart will realise that pages of RAM that have the same contents can be shared by multiple guest OSs; and to reduce RAM consumption they’ll “invent” some way to make that happen efficiently.
Finally, one day someone will decide to call the hypervisor an “OS” and decide to call the individual SaaS guest OSs “processes”.
Basically, once the efficiency problems are fixed, we’ll all realise it’s exactly the same as a modern multitasking OS anyway.
Of course then someone will decide to run the hyper-visor as a guest inside a “meta-hypervisor”, and the cycle of stupidity will repeat.
– Brendan
Most decent hypervisors already do page de-duplication.
Except that virtual machines are self contained. The state stays within them. That means they can be migrated.
So unless someone finds an easy way to migrate running processes across multiple machines without interrupting execution or dropping a single packet in the process, you’ve got a long way to go before processes become anywhere near usable for that kind of thing.
At huge cost. Page scanning is a pretty expensive process and can eat a lot of CPU and memory bandwidth, and so it’s turned on only in environments where the expected benefits outweigh the costs (VDI, mostly).
Let’s also not forget why you’re doing memory dedup: because you had the information and threw it out at the guest-hypervisor boundary. Why not simply keep the info in the first place by disposing of this boundary, instead of trying to glean it from the bits of scrap left from the VM and reconstructing it using an expensive process?
There’s nothing in principle that prevents you from migrating user processes either. The page tables and VM mappings are available to the OS, you can recreate the virtual network stack and open file descriptors pretty easily too. Heck, OpenVZ already can do that: https://openvz.org/Checkpointing_and_live_migration
But even that’s of limited necessity. When you’re looking at starting up userspace processes, boot times are virtually nonexistent, so you might as well keep persistent state on an NFS mount and use something like Pacemaker to migrate a container by simply tearing it down and setting it up on a different machine (if you can accept a couple of seconds downtime).
So why aren’t OS’s pursuing that instead of hypervisors? The only OS I’m aware of that really supported process migration is Amoeba, which was a research system and appears to have gone no further.
But OpenVZ instances are lightweight containers…which is precisely the sort of technology I’m talking about.
Because it’s still an incredibly clumsy solution for most uses. When you design an app that’s supposed to be clustered, you build that in from the top of the stack, rather than bolting it on as an add-on feature at the bottom of the stack. For example, why would I need to migrate over an apache instance, when I can just grab pacemaker and have it start up and tear down processes on machines as I need it to?
You were talking about “virtual machines” and “hypervisors”, which are quite unlike lightweight containers, though it could be simply because we are confusing the terms here. To be more specific, I’m advocating for using OS-level virtualization with a single kernel and separate userspace containers. But that’s not a “library OS” like MirageOS or OSv – those are full blown virtual machines running on HVM and a true hypervisor and it’s my contention that they are a solution in search of a problem. Pretty much all of the problems that they do address are already solved by using OS-level virtualization in a much more efficient and simple manner.
Really, so you know of an OS that is ready “out-of-box” that can run Haiku-OS, Windows, Mac-OS and Linux at the same time out of the box?
Unless, I am reading the article wrong, this is a light OS that will support multi-VMs that can even be different OSes at the same time.
Or did I misunderstand.
I think you did – this is about a purebreed guest OS, meant to eliminate the OS elements you don’t really need when running under a hypervisor.
Edited 2014-01-17 10:23 UTC
…they are using OCaml as the OS systems language.