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

Gone Full Unikernel

deferpanic.com

Post reply on HN
Print view View original

31–40 of 98 posts

Re: Gone Full Unikernel

#31

Post by mwcampbell »

en4bz wrote: post #25
haberman wrote: post #11

Tell me if I'm missing something, but the premise of Unikernels seems to be that a ring-0 x86 hardware environment is the perfect fit for a universal container/host interface. Or to put it more charitably, since cloud compute services are based around booting VM images based on this model, we'll just go with it instead of trying to use an abstraction that is actually designed for this. Correct me if I'm wrong, but it…

We've gone full circle. Originally there was shared hosting whiched hosted your app in ring 3 with other users on the same physical machine running which ran in ring 0. Then we got fancy virtualization hardware where the hypervisor ran in ring -1, your VM ran in ring 0 and your apps ran in ring 3. But that's a lot of indirection so micro kernels move your app into ring 0. So now we're basically back at shared hosting…

> Unfortunately not many providers do this yet.

Samsung just acquired Joyent, which provides multi-tenant container hosting on bare metal via Illumos and LX-branded zones. So to me, the acquisition further validates that approach.

Re: Gone Full Unikernel

#32

Post by mwcampbell »

lmm wrote: post #17
haberman wrote: post #11

Tell me if I'm missing something, but the premise of Unikernels seems to be that a ring-0 x86 hardware environment is the perfect fit for a universal container/host interface. Or to put it more charitably, since cloud compute services are based around booting VM images based on this model, we'll just go with it instead of trying to use an abstraction that is actually designed for this. Correct me if I'm wrong, but it…

Yeah. The right thing is hosting providers offering Java application servers or equivalent. Unfortunately there are political and commercial reasons that's not happening. Still, there are worse container/host interfaces. It could be the full suite of POSIX system calls.

> Still, there are worse container/host interfaces. It could be the full suite of POSIX system calls.

Why would a Java application server provided by the host be better than the full suite of POSIX system calls?

Re: Gone Full Unikernel

#33

Post by brendangregg »

ryao wrote: post #29
brendangregg wrote: post #23

Earlier quoted context omitted.

I wouldn't say that unikernels were entirely undebuggable. I spent a few hours hacking and came up with a proof of concept dom0 profiler, and learned some debugging benefits: one symbol table for the entire binary, one place to turn on frame pointers for everything, etc. http://www.brendangregg.com/blog/2016-01-27/unikernel-profil...

That requires having access to dom0, which is not available on Amazon EC2 (for good reason). Running in UNIX binary mode in a container on bare metal seems like the way to go here. That does not have the overhead of hardware virtualization. That means no internal memory fragmentation from partitioning RAM, the ability to avoid duplication of cache and any hypervisor upcalls become normal system calls. At that point,…

We already get hypervisor statistics from dom0, via cloud watch. Could that include on-demand profiling as well? I don't see why not. And that's not the only way to solve this.

So work needs to be done to make unikernels profileable & debuggable. I wouldn't claim that this was impossible.

Re: Gone Full Unikernel

#35

Post by bogomipz »

wmf wrote: post #12
haberman wrote: post #11

Tell me if I'm missing something, but the premise of Unikernels seems to be that a ring-0 x86 hardware environment is the perfect fit for a universal container/host interface. Or to put it more charitably, since cloud compute services are based around booting VM images based on this model, we'll just go with it instead of trying to use an abstraction that is actually designed for this. Correct me if I'm wrong, but it…

Yeah, but if you use containers you have to suffer the indignity of the creat() system call. These seem like the smallest possible objections.

Can you explain why the creat() sys call lack dignity and how that relates to containers?

Re: Gone Full Unikernel

#36

Post by niftich »

nostrademons wrote: post #22
haberman wrote: post #11

Tell me if I'm missing something, but the premise of Unikernels seems to be that a ring-0 x86 hardware environment is the perfect fit for a universal container/host interface. Or to put it more charitably, since cloud compute services are based around booting VM images based on this model, we'll just go with it instead of trying to use an abstraction that is actually designed for this. Correct me if I'm wrong, but it…

The premise of unikernels is that: 1. The job of an OS is to ensure that multiple programs can run on a single box without interfering with each other. 2. The job of a hypervisor is to ensure that multiple OSes can run on a physical box without interfering with each other. 3. In many cloud deployments, a single VM instance only runs a single user-defined program, which is programmed to a higher-level runtime than the…

I tried to read up on this, but I'm not too familiar with the terminology. Are unikernels the formal name for the idea of running your application 'bare metal'?

In the parent post, does AMI mean Amazon Machine Image, or some Application M____ Interface?

Re: Gone Full Unikernel

#37

Post by ryao »

brendangregg wrote: post #33
ryao wrote: post #29

Earlier quoted context omitted.

That requires having access to dom0, which is not available on Amazon EC2 (for good reason). Running in UNIX binary mode in a container on bare metal seems like the way to go here. That does not have the overhead of hardware virtualization. That means no internal memory fragmentation from partitioning RAM, the ability to avoid duplication of cache and any hypervisor upcalls become normal system calls. At that point,…

We already get hypervisor statistics from dom0, via cloud watch. Could that include on-demand profiling as well? I don't see why not. And that's not the only way to solve this. So work needs to be done to make unikernels profileable & debuggable. I wouldn't claim that this was impossible.

I do not dispute that it is possible to profile/debug unikernels on future cloud infrastructure. However, I am skeptical that unikernels offer any benefit to merit the work of enabling that when the whole system is considered.

System calls might be additional overhead when there is a hypervisor, but hypervisors are unnecessary when we have containers. You stand to eliminate much more overhead from eliminating the hypervisor than you stand from eliminating the syscalls. Some of that overhead is internal fragmentation from memory partitioning, duplication of driver code, potential double caching, etcetera.

The industry is in the early stages of a transition from hardware virtualization to containers because containers are a better abstraction than hardware virtualization. Joyent offers Illumos zones, Swiscomm offers docker containers with flocker (full disclosure: my employer is the author of flocker), Microsoft has deployed drawbridge on their Azure cloud, etcetera. We will only see more of this in the future.

Once the transition is complete, I see no advantage to unikernels. You could use them in UNIX binary mode, but that makes them little more than a standard process on a traditional system. That is a very different role than the one that their creators intended for them.

Re: Gone Full Unikernel

#38

Post by TempleOS »

TempleOS is based on Divine Authority to bully the industry.

God says... toothbrush's arson's Rodriguez's carjacker within's unwind closeness penchant's enjoys domed misdo quaver's figment's Aldo's conquerors hostility's eying zeal perverting Novocain's marvel reward's reconsiders Topsy's slumlord's rosier tortoise's upon stockade lectern crib miscue's

Re: Gone Full Unikernel

#39

Post by andrewstuart »

bogomipz wrote: post #14

Can someone explain why these rump kernels can not be run on AWS if deferpanic has Xen as a target? AWS is Xen-based. I understand that there currently isn't a target for Docker so that takes Google Cloud out of the equation. The following two statement seem to be contradictory: Can I use Google Cloud or AWS? You could - although you won’t write much more than a toy app - not until things are changed. DeferPanic offe…

Unikernels run fine on AWS.

It's just that it's a bit fiddly to make it happen. My guess is that it's the fiddliness that Ian is suggesting is impractical.

Re: Gone Full Unikernel

#40

Post by brendangregg »

ryao wrote: post #37
brendangregg wrote: post #33

Earlier quoted context omitted.

We already get hypervisor statistics from dom0, via cloud watch. Could that include on-demand profiling as well? I don't see why not. And that's not the only way to solve this. So work needs to be done to make unikernels profileable & debuggable. I wouldn't claim that this was impossible.

I do not dispute that it is possible to profile/debug unikernels on future cloud infrastructure. However, I am skeptical that unikernels offer any benefit to merit the work of enabling that when the whole system is considered. System calls might be additional overhead when there is a hypervisor, but hypervisors are unnecessary when we have containers. You stand to eliminate much more overhead from eliminating the hyp…

Price/performance always wins.

Can an application unikernel on a hypervisor (which is really a lightweight OS that nowadays supports many pass-through features) beat performance of an application on a regular OS? (I didn't mention containers, since they should ultimately be irrelevant to hot path performance). So can it? With a lot of work, I bet they can.

So who has has the better price/performance? That's going to depend on how much engineering work it is to adopt, fix, and use unikernels, when they are competing with an established ecosystem around Linux and containers. And that may be where unikernels actually loses on price/performance, where price includes total cost of ownership. We'll see!

Post reply on HN