Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unikernels: Rise of the Virtual Library Operating System

queue.acm.org

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Unikernels: Rise of the Virtual Library Operating System

#11

Post by jasonwatkinspdx »

mbreese wrote: post #2

Is 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…

Database storage managers could get some advantages by having direct access to the memory page maps.

Re: Unikernels: Rise of the Virtual Library Operating System

#12

Post by hcarvalhoalves »

stormbrew wrote: post #4
mbreese wrote: post #2

Is 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…

> Reproducibility and uniformity of environment (...)

Shouldn't the unikernel approach actually improve reproducibility greatly? You build your application and all it's dependencies together, that should run exactly the same locally or on your Xen cloud.

Re: Unikernels: Rise of the Virtual Library Operating System

#13

Post by michaelmior »

stormbrew wrote: post #10
michaelmior wrote: post #5

Earlier 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…

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 conclusi…

Fair point. More benchmarks need to happen before it's obvious this is really a win. A real application would be nice. I'm biased because I worked on a similar idea myself and I've been waiting for this to come. I think it's a potential win now for running on public clouds.

However, as Docker PaaS gains popularity, that may be a better alternative. Only benchmarks will tell :)

Re: Unikernels: Rise of the Virtual Library Operating System

#14

Post by foobarian »

erichocean wrote: post #9
mbreese wrote: post #2

Is 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.

I don't get this. Maybe you can win big if you start with an inefficient system but a run of the mill Linux box has been able to saturate gigabit links without breaking a sweat for a decade if not more.

Things like file descriptor limits or numbers of connections are more of a pain in modern times, not necessarily a context-switch caused problem.

Re: Unikernels: Rise of the Virtual Library Operating System

#15

Post by cwzwarich »

stormbrew wrote: post #10
michaelmior wrote: post #5

Earlier 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…

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 conclusi…

You can use I/O virtualization to allow direct hardware access in a safe fashion, assuming that your CPU and peripherals support it.

Re: Unikernels: Rise of the Virtual Library Operating System

#16

Post by justincormack »

michaelmior wrote: post #13
stormbrew wrote: post #10

Earlier quoted context omitted.

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 conclusi…

Fair point. More benchmarks need to happen before it's obvious this is really a win. A real application would be nice. I'm biased because I worked on a similar idea myself and I've been waiting for this to come. I think it's a potential win now for running on public clouds. However, as Docker PaaS gains popularity, that may be a better alternative. Only benchmarks will tell :)

What did you work on?

Re: Unikernels: Rise of the Virtual Library Operating System

#17

Post by justincormack »

foobarian wrote: post #14
erichocean wrote: post #9

Earlier quoted context omitted.

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.

I don't get this. Maybe you can win big if you start with an inefficient system but a run of the mill Linux box has been able to saturate gigabit links without breaking a sweat for a decade if not more. Things like file descriptor limits or numbers of connections are more of a pain in modern times, not necessarily a context-switch caused problem.

Gigabit is slow. Saturating 10Gb+ is where the sweat might be broken or not. See eg netmap https://github.com/aarrpp/netmap which is in FreeBSD.

Re: Unikernels: Rise of the Virtual Library Operating System

#18

Post by avsm »

mbreese wrote: post #2

Is 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…

No, the idea is a bit broader. By structuring your application in a modular set of libraries, you can break up the "ambient dependencies" (e.g. the monolithic kernel) into what your application actually needs.

Once that's done, the Xen backend is just a matter of filling in the missing kernel components with OCaml libraries (or, in the case of OSv, with C libraries, or in HalVM's, Haskell libraries).

In the case of MirageOS though, we're using this fine-grained dependency control to implement other backends too. For instance, compiling the same source code to run as a FreeBSD kernel module or as a JavaScript library. There's already a Unix backend, so nothing special needs to happen to run it under Docker.

Re: Unikernels: Rise of the Virtual Library Operating System

#19

Post by michaelmior »

justincormack wrote: post #16
michaelmior wrote: post #13

Earlier quoted context omitted.

Fair point. More benchmarks need to happen before it's obvious this is really a win. A real application would be nice. I'm biased because I worked on a similar idea myself and I've been waiting for this to come. I think it's a potential win now for running on public clouds. However, as Docker PaaS gains popularity, that may be a better alternative. Only benchmarks will tell :)

What did you work on?

A similar yet much simpler idea of porting some simple application code to MiniOS. Although I never ended up with anything of value.

Re: Unikernels: Rise of the Virtual Library Operating System

#20

Post by avsm »

hcarvalhoalves wrote: post #12
stormbrew wrote: post #4

Earlier 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…

> Reproducibility and uniformity of environment (...) Shouldn't the unikernel approach actually improve reproducibility greatly? You build your application and all it's dependencies together, that should run exactly the same locally or on your Xen cloud.

That's exactly right. Since everything's a library, the normal OCaml dependency analysis pulls in a complete manifest of everything that goes into the final output. In the Xen output mode, this implies that the manifest contains everything. In the Unix backend, you still need to package up the kernel and library dependencies.

An example of this is the Mirage website itself, where all the kernel outputs that are live are stored in GitHub at https://github.com/mirage/mirage-www-deployment -- an explanation of the Travis CI workflow is at http://www.openmirage.org/wiki/deploying-via-ci

Post reply on HN