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…
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…
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…
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…
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…
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).
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…
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…
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…
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…
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…
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…
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…
Interesting, do you have any references explaining how/why z/TPF is a unikernel? Thanks!
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…
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…
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…
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…
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…
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).
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…
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…
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…
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…
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…
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…
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…
Interesting, do you have any references explaining how/why z/TPF is a unikernel? Thanks!