felipehuici

Definitely agree, in fact we tend to use the term "massive consolidation", where we run thousands of VMs on a single server, thus saving costs. Unikraft unikernels are a perfect fit for this since they consume little memory and boot relatively fast. In early work [0] we were booting as many as 8000 hello world VMs/unikernels on the same server on the Xen hypervisor. More recently we have been booting 1K NGINX Unikraft images on a single server.

[0] https://dl.acm.org/doi/10.1145/3132747.3132763

For a while nanovms was based on Rump[0], which had terrible performance. The new version of nanovms[1] we haven't benchmarked but we should; having said that, even the founder says they "[...] have spent very little time benchmarking" [2]

[0] https://en.wikipedia.org/wiki/Rump_kernel

[1] https://github.com/nanovms/nanos

[2] https://www.gula.tech/blog/files/135c832f92668268f1e9140a524...

We also have support for EXT2/EXT4 but it's not open source yet.

Hi, no, the statement wasn't to isolate the kernel code from the application, since it's all in the same address space. Instead, it's to reduce the possibility of bugs (but again, not in the application), and reduce the vectors for attack in the underlying stack. For separating the application from the kernel (and from components within the kernel, since Unikraft is modular) we are doing further work called FlexOS, based on Unikraft, and to appear soon at the ASPLOS conference[0]; a short version of the paper appeared at HotOS [1].

[0] https://asplos-conference.org/program/

[1]https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s...

Agree, we're working on an embedded page, we intend to release the code during our May release. Also agree with having a page about the different languages we currently support (c/c++, Lua, Go, Python, Ruby) and others we're working on (e.g., Rust, Java). Always interested to hear which languages and/or frameworks people are interested in.

Yes, in fact we have some early support for Firecracker, where we can at least boot some basic Unikraft images with it (e.g., see page 10 of this paper[0], FIgure 10, where we get the shortest boot times with Firecracker). We're still missing networking supporto on FC, which we're working on.

[0] https://dl.acm.org/doi/pdf/10.1145/3447786.3456248

Code clean up, commit history clean up, more testing and perhaps a bit of re-basing (it was built against a somewhat older version of Unikraft).

Hi, support for the RPI and perhaps another device should be out by release 0.9 in May, along with the documentation at the link you posted (the code's working, but it needs clean-up).

Yes, correct, Unikraft generates an OS that is customized to the needs of particular applications.

You can think of the VMM as the toolstack that executes the moment you send a command to start a VM up. Once it's done it hands over execution to the actual VM (i.e., the OS within the VM). Thus the total boot time is the sum of the VMM plus the actual VM boot time. In the past, both of these took a long time. With the advent of unikernels, which can boot in as little as a few milliseconds, the focus has also been on reducing VMM time.

Agree that one of the major downsides of most unikernel projects so far has been how difficult/time consuming it was to create each unikernel -- oftentimes for each application. That's one of the explicit goals of Unikraft, to make it much easier, or seamless, to run a wide range of mainstream applications and languages.

It's also worth mentioning that a hypervisor's API, like Xen's, is much more stable; the Linux one is constantly growing.

Well, I'm pretty sure this wasn't their intended purpose :). To some extent, they come from the observation that the hypervisor already provides strong isolation, and so having things like multiple memory address spaces, syscalls, etc just brings overhead. The second point is specialization: unlike a general purpose OS like Linux, each unikernel image can be tailored, at compile time, to meet the needs of a single (or a a few) target applications. As a result of all this, it is entirely possible to have unikernels that beat Linux in terms of boot times, memory consumption, and even throughput, as explained in the paper (they can even beat bare metal Linux).

Hey, yes, you could and in some cases it might make sense (e.g., you need to do some packet processing as one app but you also want the control plane as another app in the same unikernel). Generally speaking unikernels have a single memory address space so don't support (or don't easily support) processes, so the apps would run on separate threads.

Yes, that's right. If you do not include a module that could potentially be used, you'd be missing that symbol and it would not compile.

Typically unikernels have a single application in them because then you can fully specialize the entire image to the needs of that single application. Having said that, it is entirely possible to place multiple applications in one unikernel, each in its own thread; we have done a few of these in the past.

I suppose the right answer is "it depends". For most unikernels the answer is no: they are highly specialized, often targeting a single application or language, and built on top of small/basic OSes. Some of them have targeted various levels of POSIX compatibility, e.g., OSv (http://osv.io/) and HermiTux (https://ssrg-vt.github.io/hermitux/) though they don't always support a large number of syscalls/applications. An older project was Rump (largely abandoned), which used the NetBSD kernel to be (mostly) POSIX compatible, though performance wasn't great and it's largely abandoned. An active project targeting at least partial POSIX compatibility is Unikraft (http://www.unikraft.org/).

The automotive domain definitely use them (e.g., Open Synergy and others), since their efficiency means they consume fewer resources on ECUs, and their relatively small Trusted Computing Base (TCB) not only reduces exploits but also means certification is cheaper/faster.

A hello world unikernel was reported to take 4 ms a few years back (http://cnp.neclab.eu/projects/lightvm/lightvm.pdf). Here's a more recent project: http://www.unikraft.org/ .

No, it was not Jitsu. Jitsu is based on MiragOS/OCaml, Erlang-on-Xen was also a Xen-based unikernel like MirageOS but was (as you can guess) Erlang specific. I think you can now find it at https://github.com/cloudozer/ling .

Interesting, do you have any references explaining how/why z/TPF is a unikernel? Thanks!