Run Mirage Unikernels on KVM/QEMU with Solo5


[from the original at:]

I’m excited to announce the release of Solo5! Solo5 is essentially a kernel library that bootstraps the hardware and forms a base (similar to Mini-OS) from which unikernels can be built. It runs on fully virtualized x86 hardware (e.g., KVM/QEMU), using virtio device interfaces.

Importantly, Solo5 is integrated (to some extent) with the MirageOS toolstack, so the Solo5 version of the Mirage toolstack can build Mirage unikernels that run directly on KVM/QEMU instead of Xen. As such, Solo5 can be considered an alternative to Mini-OS in the Mirage stack. Try it out today!

In the rest of this post, I’ll give a bit of motivation about why I think the lowest layer of the unikernel is interesting and important, as well as a rough overview of the steps I took to create Solo5.

Continue reading …


I built and ran the console example under qemu (can’t use KVM as already running under Xen…) - seems to work nicely!


We’d be interested in collaborating on a common virtio-layer for IncludeOS, Mirage + anyone who wants to run on KVM/Qemu with Virtio. The Virtio standard is probably going to keep evolving and collaborating on a single set of drivers would be nice. Looks like the things common to IncludeOS and Mirage on KVM is Virtio + very basic interrupts. We’d like to do everything with a C++ compiler but we could do an ABI with C linkage.

That kind of layering could possibly also be a step towards getting IncludeOS on paravirtual xen, but I’m not at all familiar with Xen hypercalls.

Any thoughts?


An ABI with C linkage is the way to go; Mirage has OCaml-Ctypes library that @yallop wrote which makes it easy to wrap.

Before considering the specifics of the interop though, it would be good to ensure that the lowest level APIs are compatible – for instance, the best way to wrap memory pages between IncludeOS and MirageOS so that there is no inherent copying in the interface. MirageOS is event-driven, so interrupts should be straightforward.


@alfred_bratterud - I agree that it would be good to have some standalone virtio drivers that could be easily reused across projects. Thanks for the pointer to the up-to-date virtio spec. I wrote the Solo5 virtio drivers based on the out-of-date 0.9.5 spec. They are simple and unoptimized, mostly just so I could learn the interface.

I should admit that a better virtio layer is not currently on my critical path, and in fact I’m starting to question whether unikernels should necessarily stick to “legacy” hypervisor interfaces in the future. Nevertheless, good standalone implementations are always a good thing!

@avsm - I’m surprised that you aren’t advocating for implementing more of the virtio drivers in OCaml for Mirage, more like the Xen drivers. Is there something about virtio that would make that difficult?


Hi @djwillia - nice to see you here! It’s really interesting to look into all the possible ways to isolate services; from pure emulation (arm on x86), to augumented emulation (Java with JIT) to hypercalls and containers. For my part I’m a big fan of Popek-Goldberg virtualization. The complete isolation it offers makes everything very portable (i.e. we can run on Windows / Mac / Linux with virtualbox) and the simplicity of an instruction-level isolation mechanism like that makes it easy to reason about it mathematically.

I’m certainly interested in higher-level interfaces, and we do have a project going to port the IncldueOS interface ported to userspace Linux. But I guess our priority is efficient, robust and portable Popek-Goldberg first, then everything else. Please let us know if you want to go any further with the virtio drivers - we’d love to collaborate.

And @avsm - I agree, C-linkage for ABI is a good approach - we can do that with a C++ compiler (unless there’s a good reason not to?), which will just be a bit stricter about explicit type casts etc. The linker won’t know the difference. Regarding compatibility with Mirage; is there an easy way to find the low-level requirements / ABI interface for it?