| ___| __| _ \ | _ \ __ \ \__ \ ( | | ( | ) | ____/\___/ _|\___/____/
Solo5 originally started as a project by Dan Williams at IBM Research to port MirageOS to run on the Linux/KVM hypervisor. Since then, it has grown into a more general sandboxed execution environment, suitable for running applications built using various unikernels (a.k.a. library operating systems), targeting different sandboxing technologies on diverse host operating systems and hypervisors.
Some of the unique features of Solo5:
- a public API designed for ease of porting existing and future unikernel-native applications,
- a host to guest interface designed with isolation, a minimal attack surface and ease of porting to different sandboxing technologies or host systems in mind,
- a minimal, modular monitor which implements this interface using hardware virtualization (several orders of magnitude smaller than QEMU),
- support for live and post-mortem debugging of unikernels,
- fast "boot" times (comparable to loading a standard user process), suitable for "function as a service" use-cases.
Looking for the ukvm monitor? Ukvm is only one component of Solo5, and due to be renamed to a better name shortly to reflect that it is no longer specific to the KVM hypervisor.
As Solo5 is essentially a piece of "middleware" interfacing unikernel-style applications with their host systems, it is not an end-developer product as such.
To get started as a developer with Solo5, please refer primarily to the instructions provided by the unikernel project you intend to develop applications with:
That said, we provide the following documentation, not specific to any unikernel in particular:
- Building Solo5 and running Solo5-based unikernels
- Debugging Solo5-based unikernels
- Technical overview, goals and limitations, and architecture of Solo5
Contributing and community
Solo5 is developed on GitHub and licensed under a liberal ISC license. We
accept contributions via GitHub pull requests. When submitting a contribution,
please add your details to the
AUTHORS file, and if your contribution adds
new source files copy the copyright header from an existing source file.
The coding style for the project is "as for the Linux kernel, but with 4 spaces instead of tabs". When in doubt, please follow style in existing source files.
We operate a mailing list for general Solo5 development discussion, at firstname.lastname@example.org. To subscribe to the list, send an empty email to email@example.com. Archives are available at The Mail Archive.
If you are considering a substantial contribution to Solo5, would like to port a new unikernel to Solo5, or have general questions unrelated to a specific unikernel, please get in touch via the mailing list.