Comment by ryukoposting | Hacker News Reader

Comment by ryukoposting | Hacker News Reader

I'm an embedded guy by trade, so the idea of a Unikernel is nothing new to me. But wait... use cases overlapping with general-purpose OSes? nginx benchmarks??? This is exciting.

I know DevOps for bare-metal firmware is a PITA partly because of the tightly-coupled application, kernel, and libraries. I'm hoping someone familiar with Unikraft/OSv/etc could sate my curiosity...

- Do you test your app inside a container before building your Unikraft/OSv image? Or is there a way to create a CI/CD pipeline that builds your unikernel executable + tests the whole thing as a compiled unit?

- How often do bugs appear in Unikraft that don't appear when running the app on a traditional OS? To what extent does the complexity of the app's dependencies affect this?

- In terms of convenience, how does Unikraft/OSv compare to using a highly-customizable general-purpose* OS like Gentoo?

(*edit for clarity: "general-purpose OS" in the sense that it 1) can load arbitrary data using one or more filesystems 2) can execute loaded data as a program 3) has means by which a human or human-controlled machine may cause the OS to load and execute said programs. This definition does not exclude highly-specialized Gentoo/Nix/whatever setups that are tailored to run a particular program)

1. We build unikernels using the 'kraft container' which is Docker/OCI image[0][1] which has the necessary build tools to build Unikraft unikernels. We plug this into Concourse CI which builds thousands of combinations of Unikernels[2] as part of our code review process[3]. In addition to this, we have on-going research and tooling to help automatically discover permutations of Unikernel builds[4]. We then run the unikernel natively using the target platform/hardware combination or use QEMU emulation.

2. Really great question, but mostly you can expect the same functionality of an application when it runs as a unikernel because the application "thinks" it's still running in a traditional OS environment -- as it should be. Check out this documentation[5] (after step 7) about porting, it has snippets about where the boundary sometimes breaks. Even then, you can run it in POSIX-compatibility mode[6].

3. Well, general-purposes are not suited for deployment environments (which is what Unikraft is suited for). Installing Gentoo (or Ubuntu, Debian, for that matter) is a waste of resources if you only SSH in once to install your desired application.

[0]: https://unikraft.org/docs/usage/install/#docker

[1]: https://github.com/unikraft/kraft/tree/staging/package/docke...

[2]: https://builds.unikraft.io

[3]: https://unikraft.org/docs/contributing/review-process/#stage...

[4]: https://github.com/lancs-net/wayfinder

[5]: https://unikraft.org/docs/develop/porting/#providing-build-f...

[6]: https://unikraft.org/docs/features/posix-compatibility/

I edited my comment to clarify this, but I meant "general-purpose OS" in a very broad sense - i.e. not much more than "can it load, execute, and time-share between arbitrary programs loaded from an attached storage device."

Thanks for the links!

The application code is compiled along with kernel code so you can think of unikernels as a single-process VM, there's nothing else running other than the application so it boots straight to `main()`. Unikraft just facilitates the runtime of the application to be able to run as a VM or on baremetal. There's no shell, so you can't instantiate another program from disk. If the application wishes to read and write from an attached storage, it can, but it can't start another process if it's reading application code to-be-executed. Starting another process is a bit tricker since there is no `fork()` to execute another process. Interesting work is being done to enable multi-threading across cores via SMP[0] however and to provide fork like ability but with regard to the application's logic[1] but not in a wider general multi-processing environment. I hope this clarifies things.

[0]: https://github.com/unikraft/unikraft/pull/244

[1]: https://xen2021.sched.com/event/jAME/cloning-unikernels-on-x...

I'm familiar with unikernels as a concept - heck, I wrote (a bad) one for a research project during my undergrad with embedded systems and softcore processors as the target. It's exciting to see unikernels being used with software of a similar scale, but with a much more broad solution space.

Reply on news.ycombinator.com