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 appli

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 https://github.com/unikraft/unikraft/pull/244 [1]: https://xen2021.sched.com/event/jAME/cloning-unikernels-on-xen-costin-lupu-university-politehnica-of-bucharest https://xen2021.sched.com/event/jAME/cloning-unikernels-on-x...