Unikernels: Rise of the Virtual Library Operating System
1–10 of 23 posts
Re: Unikernels: Rise of the Virtual Library Operating System
#2Is the idea that you'd compile a virtualized OS in with your application to produce one really streamlined VM appliance? I get that you'd be able to avoid the overhead of the OS in the VM but effectively making the VM a single application again.
Is this any better than the Docker method of reusing the same base-OS and compartmentalizing the applications? Is there that much to be gained in avoiding kernel/user-space transitions?
Re: Unikernels: Rise of the Virtual Library Operating System
#3Is the idea that you'd compile a virtualized OS in with your application to produce one really streamlined VM appliance? I get that you'd be able to avoid the overhead of the OS in the VM but effectively making the VM a single application again. Is this any better than the Docker method of reusing the same base-OS and compartmentalizing the applications? Is there that much to be gained in avoiding kernel/user-space t…
Those are great questions, I was wondering about the latter myself.
Re: Unikernels: Rise of the Virtual Library Operating System
#4Is the idea that you'd compile a virtualized OS in with your application to produce one really streamlined VM appliance? I get that you'd be able to avoid the overhead of the OS in the VM but effectively making the VM a single application again. Is this any better than the Docker method of reusing the same base-OS and compartmentalizing the applications? Is there that much to be gained in avoiding kernel/user-space t…
I think the real problem with this sort of idea is that, in the end, you're just reinventing processes. There's already a way to write an isolated single purpose application and run it on a server: fork() and then exec().
If you want to bring the isolation level of that process down to just absolutely what it needs to run we've got things like jails and cgroups. You could probably run a Go app with no access to the filesystem since everything is linked in statically anyways.
I think it misses the reasons people are excited about virtualization. Reproducibility and uniformity of environment has a higher value than isolation to most software developers. The priorities may be inverted on the sysadmin side, but I don't think so far as to justify this kind of approach.
Re: Unikernels: Rise of the Virtual Library Operating System
#5Is the idea that you'd compile a virtualized OS in with your application to produce one really streamlined VM appliance? I get that you'd be able to avoid the overhead of the OS in the VM but effectively making the VM a single application again. Is this any better than the Docker method of reusing the same base-OS and compartmentalizing the applications? Is there that much to be gained in avoiding kernel/user-space t…
I think the real problem with this sort of idea is that, in the end, you're just reinventing processes. There's already a way to write an isolated single purpose application and run it on a server: fork() and then exec(). If you want to bring the isolation level of that process down to just absolutely what it needs to run we've got things like jails and cgroups. You could probably run a Go app with no access to the f…
My understanding is that the goal is not isolation, but performance. You can remove large chunks of the OS which you don't need. You also don't have any overhead from system calls since all code runs at the same privilege level. This is possible because (in theory) you can't execute arbitrary code. All the executable code is baked into the kernel at compile time and the page tables are sealed so no new code can be loaded.
You can achieve the isolation with jails and cgroups, but not the performance improvements.
Re: Unikernels: Rise of the Virtual Library Operating System
#6Earlier quoted context omitted.
I think the real problem with this sort of idea is that, in the end, you're just reinventing processes. There's already a way to write an isolated single purpose application and run it on a server: fork() and then exec(). If you want to bring the isolation level of that process down to just absolutely what it needs to run we've got things like jails and cgroups. You could probably run a Go app with no access to the f…
My understanding is that the goal is not isolation, but performance. You can remove large chunks of the OS which you don't need. You also don't have any overhead from system calls since all code runs at the same privilege level. This is possible because (in theory) you can't execute arbitrary code. All the executable code is baked into the kernel at compile time and the page tables are sealed so no new code can be lo…
You've eliminated system calls but you have hypercalls; it's not clear whether this is faster than a container-based system that has system calls but no hypercalls.
Re: Unikernels: Rise of the Virtual Library Operating System
#7Earlier quoted context omitted.
My understanding is that the goal is not isolation, but performance. You can remove large chunks of the OS which you don't need. You also don't have any overhead from system calls since all code runs at the same privilege level. This is possible because (in theory) you can't execute arbitrary code. All the executable code is baked into the kernel at compile time and the page tables are sealed so no new code can be lo…
You've eliminated system calls but you have hypercalls; it's not clear whether this is faster than a container-based system that has system calls but no hypercalls.
True. Of course one other advantage is that you can run a unikernel on a public cloud. You can of course run OS to serve as a host for containers on a public cloud, but then you have an additional layer of overhead.
Re: Unikernels: Rise of the Virtual Library Operating System
#8Earlier quoted context omitted.
You've eliminated system calls but you have hypercalls; it's not clear whether this is faster than a container-based system that has system calls but no hypercalls.
True. Of course one other advantage is that you can run a unikernel on a public cloud. You can of course run OS to serve as a host for containers on a public cloud, but then you have an additional layer of overhead.
I wish there was more experimentation on cloud architecture; VMs aren't the be-all and end-all of the cloud IMO.
Re: Unikernels: Rise of the Virtual Library Operating System
#9Is the idea that you'd compile a virtualized OS in with your application to produce one really streamlined VM appliance? I get that you'd be able to avoid the overhead of the OS in the VM but effectively making the VM a single application again. Is this any better than the Docker method of reusing the same base-OS and compartmentalizing the applications? Is there that much to be gained in avoiding kernel/user-space t…
Is there that much to be gained in avoiding kernel/user-space transitions?
Yes, there's at least an order-of-magnitude improvement in packet processing, for example, if you bypass the kernel.
Our mobile app runs WebSocket-like connections over UDP with libsodium for crypto, and we're moving our stack off of Node.js for exactly that reason.
Re: Unikernels: Rise of the Virtual Library Operating System
#10Earlier quoted context omitted.
I think the real problem with this sort of idea is that, in the end, you're just reinventing processes. There's already a way to write an isolated single purpose application and run it on a server: fork() and then exec(). If you want to bring the isolation level of that process down to just absolutely what it needs to run we've got things like jails and cgroups. You could probably run a Go app with no access to the f…
My understanding is that the goal is not isolation, but performance. You can remove large chunks of the OS which you don't need. You also don't have any overhead from system calls since all code runs at the same privilege level. This is possible because (in theory) you can't execute arbitrary code. All the executable code is baked into the kernel at compile time and the page tables are sealed so no new code can be lo…
As mentioned in a sibling you still have the hypercalls, and you definitely need those to still be present if you're running at ring 0 since, essentially, direct access to the hardware is probably an opportunity to attack the whole physical system (since hardware often has arbitrary bus access). Never mind the need to arbitrate access between multiple VMs.
And this is what I mean when I say that taken to its conclusion you're just reinventing processes.
I think this kind of performance claim needs to be solidly proven by something at least vaguely like a real running application to be taken as a given.