The Solo5 Unikernel | Hacker News Reader

The Solo5 Unikernel

github.com

37 pointsingve6 comments

There's a lot of activity going on in this space right now, which is great. I was working on my own project very similar to this one, which I called 'fleet':

http://www.github.com/marssaxman/fleet/

I've recently decided to stop working on this and to start contributing to IncludeOS instead, since they have a lot of energy and good ideas, and they're getting farther than I was on my own:

http://www.github.com/hioa-cs/IncludeOS/

One great thing about unikernels is that fragmentation is not really a problem: it's a good thing to have a healthy, diverse ecosystem of unikernel libraries adapted for different purposes.

> "One great thing about unikernels is that fragmentation is not really a problem: it's a good thing to have a healthy, diverse ecosystem of unikernel libraries adapted for different purposes."

I agree with having a diverse set of libraries but we need to take care that we solve common problems in a consistent way. For example, passing config parameters into unikernels, how they get deployed to common cloud platforms and even how we monitor and log activity. For unikernels to become mainstream, we need to ensure we don't fragment this part of the toolchain (silos won't help adoption). It's part of why https://devel.unikernel.org exists -- to share solutions and converge on tooling.

There's an introductory blog post at https://mirage.io/blog/introducing-solo5

(And a new discussion site for unikernel development at https://devel.unikernel.org)

from the https://mirage.io/blog/introducing-solo5

> So far I've found that generating a bootable iso with GRUB as a bootloader and relying on QEMU to emulate BIOS calls to load the kernel is, by the nature of emulation, inefficient and something that should be avoided.

afaik, loading the unikernel directly with `qemu -kernel` avoids that?

> afaik, loading the unikernel directly with `qemu -kernel` avoids that?

(author here)

Thanks for this. I believe you are correct, though I have not yet had a chance to benchmark it.

It seems like there are a few different "shortcuts" that pre-load the kernel into memory (like `qemu -kernel`) from different tools. For example, I know also of `kvmtool` used in the clear containers project[1].

I'm not sure if all of them choose multiboot[2] as their standard and it's not clear how much of a traditional boot could or should be pushed into the hypervisor. `kvmtool` prepares a 64-bit environment with the Linux "zero page" structure instead of multiboot.

From a unikernel perspective I think this is an interesting question to ask, because typical CPU setup including page tables (direct map is common for such a simple kernel) and segment registers, etc. will likely all be boilerplate. It will almost certainly be faster to preload the CPU and memory than to do it at boot time. (At the cost of reducing the number of hypervisors that can boot the kernel)

[1]: https://lwn.net/Articles/644675/ [2]: https://www.gnu.org/software/grub/manual/multiboot/multiboot...

Interesting project. I'm curious why he called it Solo5 in case I've seen what inspired it.

Reply on news.ycombinator.com