3 ms·

I think the biggest problem with Unikernels that I haven't seen addressed is hypervisor inefficiency. Emulating any part of a kernel or multiple kernels will j

I think the biggest problem with Unikernels that I haven't seen addressed is hypervisor inefficiency. Emulating any part of a kernel or multiple kernels will just be slower. You have 20 guests on your hosts? That's 20 probably-overlapping (uni)kernels running. Sure you could optimize the heck out of the hypervisor, but now you've created a kernel. And your applications run on that kernel. With containers, you have one kernel that won't have to instantiate 20 drivers for the disk subsystem. It can be smarter because it knows more about the loads. It's what kernels have been built to do since day 0. My main concern with unikernels is that eventually the hypervisor will need to be a kernel to be any more optimized. I just worry it will be come something of a self-defeating concept.

m0th87 12y ago
AWS, Rackspace et al. use hypervisors already, so we're trending toward 4 layers: hypervisor -> monolithic kernel -> containers -> application Unikernels collapse it to: hypervisor -> unikernel/application It's certainly more elegant, although I'm skeptical of the purported performance gains as well, simply because so many optimizations have been thrown into traditional kernels.
- jdf 12y ago
  If you are using a more minimal hypervisor (see my other comment on the parent), then there do seem to be some measurable gains. I've seen a few papers in this style: https://www.usenix.org/conference/osdi14/technical-sessions/presentation/peter https://www.usenix.org/conference/osdi14/technical-sessions/... We describe the hardware and software changes needed to take advantage of this new abstraction, and we illustrate its power by showing improvements of 2-5 in latency and 9 in throughput for a popular persistent NoSQL store relative to a well-tuned Linux implementation. That said, a simple application like memcached might be currently latency-bound by the kernel's network stack, but a more complex application that reads from disk (even SSD) won't be.
rwmj 12y ago
This is unavoidable, because the aim for unikernels is to run on the cloud as a platform. They don't get to do or see anything in the hypervisor (or between guests) because the hypervisor is owned and managed by someone else who very much does not want you to see what's going on.
justincormack 12y ago
The idea is to avoid overlapping and emulation. You can for example pass through physical devices to the unikernel.
jdf 12y ago
If you're running a service, then you can use a much trimmer hypervisor, e.g. https://github.com/siemens/jailhouse https://github.com/siemens/jailhouse Since the guest unikernel isn't a full kernel, the hypervisor interface is much more minimal, and the few host features it needs can be delegated to the CPU via VT-X (e.g. page table mapping). At least, that's the dream. (I've never actually used Jailhouse or tried any of the research projects attempting this.)

m0th87 12y ago

AWS, Rackspace et al. use hypervisors already, so we're trending toward 4 layers: hypervisor -> monolithic kernel -> containers -> application Unikernels collapse it to: hypervisor -> unikernel/application It's certainly more elegant, although I'm skeptical of the purported performance gains as well, simply because so many optimizations have been thrown into traditional kernels.

jdf 12y ago
If you are using a more minimal hypervisor (see my other comment on the parent), then there do seem to be some measurable gains. I've seen a few papers in this style: https://www.usenix.org/conference/osdi14/technical-sessions/presentation/peter https://www.usenix.org/conference/osdi14/technical-sessions/... We describe the hardware and software changes needed to take advantage of this new abstraction, and we illustrate its power by showing improvements of 2-5 in latency and 9 in throughput for a popular persistent NoSQL store relative to a well-tuned Linux implementation. That said, a simple application like memcached might be currently latency-bound by the kernel's network stack, but a more complex application that reads from disk (even SSD) won't be.

rwmj 12y ago

This is unavoidable, because the aim for unikernels is to run on the cloud as a platform. They don't get to do or see anything in the hypervisor (or between guests) because the hypervisor is owned and managed by someone else who very much does not want you to see what's going on.

justincormack 12y ago

The idea is to avoid overlapping and emulation. You can for example pass through physical devices to the unikernel.

jdf 12y ago

If you're running a service, then you can use a much trimmer hypervisor, e.g. https://github.com/siemens/jailhouse https://github.com/siemens/jailhouse Since the guest unikernel isn't a full kernel, the hypervisor interface is much more minimal, and the few host features it needs can be delegated to the CPU via VT-X (e.g. page table mapping). At least, that's the dream. (I've never actually used Jailhouse or tried any of the research projects attempting this.)