OSv: A New Cloud Operating System For VMs
Phoronix: OSv: A New Cloud Operating System For VMs
OSv was announced during this week's Linux Foundation CloudOpen event in New Orleans. OSv is a new operating system designed for cloud computing. OSv is BSD licensed and is designed for maximum performance of single applications running atop a hypervisor...
So..... this is a brand new OS entirely? No linux or freebsd based?
I think they are aiming for Linux syscall compatibility, but with a recompile required to make it position-independent code. It is a minimalist OS which doesn't do most of the work an OS would normally do, because it doesn't need to when running virtualized with just a single application running in a single process and single address space (but multiple threads). I think this has huge potential.
Originally Posted by dh04000
Potentially one day (e.g. with link-time optimisation) all your calls through libc to syscalls could be completely optimised down to just the core actions the OSv kernel does. All that machinery (user/kernel separation, syscall interface, etc) can be eliminated. Even without optimisation, they are just function calls, not syscalls. I think this technique is definitely one to watch.
In a sense it is like the old days where people optimised and coded for specific hardware (e.g. poking Amiga chips or whatever). Only now the common hardware is whatever KVM exposes to the virtual OS.
Then we could, you know, just eliminate the whole VM and run the application natively.
Originally Posted by Aguazul
That'll be the big news in 2020. No more VMs! Gain super efficiency by running native!
The whole thing just seems silly. There's fundamentally no difference between this and just running every application as a different user. By eliminating the very features that provide security inside the VM, you're just relying on the VM itself to provide security rather than the base OS the VM runs on. I don't see any reason why we should expect the VM to be more secure than the underlying operating system.
Given the desccription of the aim of the project, even *basing* OSv on anything would have been an overkill.
Originally Posted by dh04000
According to the website: their aim is to create a minimalistic OS which only runs a single service inside a VM.
This thing will NEVER talk to real hardware BY DESIGN.
This thing will NEVER manage anything more than its single service BY DESIGN.
All the actual work done by an OS is delegated to the hypervisor or the host OS running the virtual machine.
Talking to hardware, handling actual network, managing ressource between multiple processes, etc.
So even if there are lots of interesting pieces of code in Linux or BSD (device drivers, intitialising hardware at boot time even critical stuff like memory controllers, talking to BIOS, ACPI, EFI, complex resource management, even including container, handling of multi-user, multi-tasking, etc.) they will never get picked up by OSv, because by design OSv will never ever implement them, but just talk to its virtual environment and let the virtual machine/byte code machine/host OS/hypervisor handle them.
In a way its the very opposite of opensource OS like BSD and Linux: these tends to be advertised as "Runs on everything including your toaster". Where as OSv is "Runs only in a handful VMs".
This has a few very interesting application:
- resource separation:
obviously if two services are provided by two different machines, if one service is hacked, the other machine is still secure (until the hacker breaks in too, perhaps using some access right obtained from the firts machine. But still there is a machine-to-machine barrier to go through). Physical machine make this kind of strategy expensive, virtual machine make it cheaper.
lots of admin love to put services into compartment and split as many servers as possible into as many virtual machine as possible.
but you have a huge waste of resource, because now every single virtual machine runs a full blown OS (which has the capability to run on its one hardware if needed).
there are several strategies against this:
OSv adds a new option: running a separate kernel (like the classical VMs). But that kernel is rather minimalistics. It only implements the bare strict minimum to boot inside the VM. It will never implement anything that is needed to boot on real hardware. It doesn't have any real hardware driver, only driver talking to the guest-API of the VMs.
- memory and swap compression, memory deduplication, copy-on-write, etc. basically try to merge as many resource as possible. But that only works to a certain point.
- lightweight container, like chroot, LXC, Jails, etc. This does wonder in lowering the pressure on resources as everything runs inside the same kernel. But it has a few drawbacks: you can only use the exact same (host) kernel for all your virtual servers, and if a virtual machine gets hacked and the hacker gains access to the kernel, the whole infrastructure is hosed: not only the VM, but every other VM and the host, because its all the same kernel (though LXC are making progress into compartmentalizing the kernel).
So you get part of the benefits of running a separate kernel, but avoid the wastage of running a full blown system inside your VM.
as OSv is much smaller and much minimalistic (dummy drivers for VM APIs), there is a lot less code to check for bugs and a much smaller attack surface for a hacker.
- Advanced process and io scheduler
This are very cool subjects of development inside Linux and similar and regularly gets benchmarked on Phoronix. But they aren't really mandatory for an OS running a single service in a separate VM. A very simple primitive scheduler does the trick. Most of the significant resource management happens *between* such VMs and not *inside them* and that's handled by the hypervisor or host OS (by Linux it self).
- 3D api
This is a hot topic currently intensely developped by VMware, VBox, QEMU, each with its own offering and own solution. Running just a single Apache instance doesn't need that nor even access to a frame buffer. Not even multiple consoles and virtual terminal management. A very rudimentary single console is more than everything needed.
- hardware initialisation, Northbridges support, BIOS, ACPI, EFI, sleep/wake/energy saving support, etc.
regularily subject of development, regression and improvement reported here on a regular basis. But a VM-only OS doesn't this. Only talk to the guest OS API of the VM.
This is really great. I hope this ends up being really big, I know I'm going to try it for sure.
That's pretty cool. I had no idea that you could make an OS that was design from the ground up to be a VM, and not need 90% of the components because of it. Sounds like the prefect OS for a VM if all your doing is providing single applications or application suites, which AKAIK is what 95% of servers do. Who needs the rest of the OS if that's all your doing, just overhead.
You might find this interesting :
Originally Posted by dh04000
CMS has been around for at least 40 years -- basically a single user OS that runs on a virtual IBM mainframe. It was the standard application development environment for the longest time...