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

41–50 of 98 posts

Re: Gone Full Unikernel

#41

Post by ryao »

aseipp wrote: post #8
ryao wrote: post #6

> Try 5, 10, 20 megabyte small. OpenWRT/LEDE will happily work on a system with 4MB of storage: https://www.lede-project.org QNX had a graphical environment, a web browser, a web server, a text editor, image viewer, various games, a package manager, etcetera on a 1.44MB floppy: http://m.youtube.com/watch?v=K_VlI6IBEJ0 Less is definitely more, but you do not need a Unikernel to achieve such sizes and you lose observab…

> The world moved away from such designs because the observability and stability were awful. We might have "safe" languages now that improve stability of the application, but those could just run as a process in an environment where proper debugging can be done when something goes wrong. The few percentage points of performance that you get from eliminating the mechanisms that enable you to understand what went wrong…

Unikernel proponents seem to assume that hardware virtualization will forever be the abstraction of cloud computing. However, hardware virtualization is the wrong abstraction, which is why the industry is beginning to adopt containers. There is no reason why you cannot run a unikernel in UNIX binary mode inside a container, but then it is really just a different way of developing a userland process rather than a unikernel. You definitely could still call it a unikernel. You would get the advantages of modularity that you specified and you would have all of the debuggability and observability that regular applications have today with the tools that we have today. However, that is rather different than the role in which they are intended to operate.

I guess my point is that the unikernel is always going to be the equivalent of a userland process. The question is whether your bare-metal kernel is going to be a traditional one or a hypervisor. They have definite performance advantages over a traditional kernel when your bare metal kernel is a hypervisor, but I believe that is the wrong abstraction when I consider overhead.

Re: Gone Full Unikernel

#42

Post by lifty »

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…

Hypervisors offer decent security and performance guarantees, which means they are good for sharing resources among potentially hostile customers. Their simple resource semantics and small ABI makes for a fairly secure abstraction.

Re: Gone Full Unikernel

#45

Post by moosingin3space »

rjsw wrote: post #27
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...

There is nothing stopping people from creating a unikernel for a dynamic language that also includes the development tools. A Lisp Machine on Xen would be one model.

I feel like Erlang-based unikernels are an extremely compelling alternative to traditional UNIX deployments. Immutable systems with safe hot swap and excellent debugging tools like `observer` and `debugger`.

Re: Gone Full Unikernel

#46

Post by ryao »

brendangregg wrote: post #40
ryao wrote: post #37

Earlier quoted context omitted.

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…

I suspect that the performance of a unikernel on a hypervisor vs an application on a POSIX system is somewhat analogous to the performance of hardware RAID vs ZFS. The performance of the abstraction used in the former is inherently worse than the performance of the abstraction used in the latter. The example of memory partitioning gives the latter a price/performance advantage and it is not the only one. I would be happy to be proven wrong though.

Re: Gone Full Unikernel

#47

Post by wmf »

bogomipz wrote: post #35
wmf wrote: post #12

Earlier quoted context omitted.

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?

That was just a joke. I think haberman is spot on that both x86 and Unix are crufty in their own ways and thus cruftiness isn't a good metric to judge these abstractions on.

Re: Gone Full Unikernel

#49

Post by ryao »

lifty wrote: post #42
ryao wrote: post #37

Earlier quoted context omitted.

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…

Hypervisors offer decent security and performance guarantees, which means they are good for sharing resources among potentially hostile customers. Their simple resource semantics and small ABI makes for a fairly secure abstraction.

Kernels do as well. Both have had security exploits that lead to privilege escalation. As containerization matures, I expect the security of a container host to become similar to that of a hypervisor. They are essentially doing the same thing. The only place on which they differ is the kind of abstraction that they use.

LPARs/LDOMs are a much more secure abstraction for "sharing resources among potentially hostile customers". Those physically partition at the hardware. LPARs are used on the IBM mainframes and are "EAL5 Certified". LDOMs are the SPARC equivalent, but I do not know their EAL. Both traditional kernels and various hypervisors are EAL 4 (some are called EAL4+), which is not as secure.

Re: Gone Full Unikernel

#50

Post by bogomipz »

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…

I think the premise unikernel is that of a library or app as an OS.

I'm not following why you think turning on protected mode is crazy. Can you elaborate?

Post reply on HN