Unikernels

From Xen
Jump to navigationJump to search

Xen Project has been at the forefront of the birth of Unikernels (or Cloud Operating Systems): specialized lightweight operating systems which are only intended to be used within a Virtual Machine. These Unikernels may become the core of a new form of cloud, where a single hypervisor instance can support hundreds or even thousands of VMs.

What is a Unikernel?

Normally, a hypervisor loads a Virtual Machine with a fully functional operating system, like some flavor of Linux, Windows, or one of the BSDs. These operating systems were designed to be run on hardware, so they have all the complexity needed for a variety of hardware drivers from an assortment of vendors with different design concepts. These operating systems are also intended to be multi-user, multi-process, and multi-purpose. They are designed to be everything for everyone, so they are necessarily complex and large.

A Unikernel, on the other hand, is (generally) single-purpose. It is not designed to run on hardware, and so lacks the bloat and complexity of drivers. It is not meant to be multi-user or multi-process, so it can focus on creating a single thread of code which runs one application, and one application only. Most are not multi-purpose, as the target is to create a single payload that a particular instance will execute (OSv is an exception). Thanks to this single-minded design, the Unikernel is small, lightweight, and quick.

What do Unikernels Provide?

Unikernels normally generate a singular runtime environment meant to enable single applications built solely with that environment. Generally, this environment lacks the ability to spawn subprocesses, execute shell commands, create multiple threads, or fork processes. Instead, they provide a pure incarnation of the language runtime targetted, be it OCaml, Haskell, Java, Erlang, or some other environment.

Unikernels Versus Linux Containers

Much has been made recently of the advantages of Linux Container solutions over traditional VMs. It is said by container advocates that their lightweight memory footprint, quick boot time, and ease of packaging makes containers the future of virtualization. While these aspects of containers are certainly notable, they do not spell the end of the world of the hypervisor. In fact, Unikernels may reduce the long-term usefulness of containers.

Unikernels facilitate the very same desirable attributes described by the container proponents, with the addition of an absolutely splendid security story which few other solutions can match.

What About Security?

Unikernels offer an excellent security scenario. The attack surface for these instances are quite small, as they lack the variety of functions (and, therefore, the potential flaws to be exploited) provided by standard operating systems, as well as the tools used to exploit them (there are no shells, no utilities, and no variety of programs to be leveraged if a flaw is located). Because of the design of Unikernels, it is hard to find security flaws, and even harder to find ways to exploit them.

Furthermore, many Unikernels (OSv is an exception to this) are used to compile their payloads. Rather than having a uniform operating layer which is the same for each application stack, most unikernels actually compile into the application layer, resulting in an optimized piece of code which provides exactly what the application needs in a unique footprint. This means that the attack surface on, say, a MirageOS webserver will not be the same as that of a MirageOS DNS server. Each operating layer will be unique, meaning that the attack surfaces of the operating layer will be different for each. An operating layer exploit which might penetrate one may not be successful at all on the other. This increases security tremendously by design.

How do Unikernels Interact with Xen Project?

Being Open Source, Xen Project can both create its own Unikernel and leverage those developed by others. In fact, Xen Project runs the gamut, as it works on its own Unikernel (MirageOS), is the target engine for some others (like LING), and can use entirely separate efforts (like HaLVM or OSv).

In addition, Xen Project has taken a proactive position in enabling the use of Unikernels. An example of this is the "3000 Domains" experiment, in which large numbers of VMs were attempted to be loaded on a single hypervisor host. As a result, modifications were made to the hypervisor code base to enable this concept. Watch the Video.

How Does Xen Project Facilitate Unikernel Use and Development?

Note: This section is still under active construction.

Xen Project provides a number of capabilities of interest to Unikernel developers and users:

  • Simplicity: Unikernels focus on doing the most in the smallest package. Xen Project pioneered Paravirtualization (PV), which gives Unikernels access to the hardware underlying the hypervisor layer without the Unikernel needing to implement the complex drivers needed when hardware virtualization is used. Unikernels can, of course, choose to use HVM mode and implement actual hardware drivers to speak to the virtualized hardware, but most Unikernels opt to use PV mode so they can keep things simple. Read our page on the Virtualization Spectrum to explore the differences between HVM and PV.
  • Scalability: Xen Project is constantly looking for technical factors which will permit thousands of Unikernel VMs to exist on a single host system. For example, in recent years, the Event Channel was redesigned to permit the management of thousands of VMs. Most hypervisors were originally designed to handle a just a few VMs, since even ten VMs on a single host was highly unusual just five years ago.
  • Security: The bare-metal nature of the Xen Project hypervisor (that is, there is no host operating system which creates the hypervisor) means that the attack surface of the host is smaller. Yes, there is a Control Domain, but that can be more readily secured since access to it is not needed by virtualization users. There is also early discussions of how we might be able to replace the normal Control Domain with a Unikernel version in the future, presumably with disaggregated drivers.
  • Incubation: Xen Project continues to help and promote Unikernels through the MirageOS project in the Xen Project Incubator. MirageOS has helped set up many of the concepts and approaches used by a number of Unikernel systems, and the Xen Project team is actively engaged with the MirageOS team to help move Unikernel technology forward in the industry.
  • Jump-start: Xen Project provides MiniOS, a basic Unikernel provided in source form which can be modified and expanded to jump start your own Unikernel project. ClickOS and Rump kernels are among the Unikernel systems which leveraged MiniOS to start their own projects.
  • Performance: The bare-metal nature of Xen Project allows us to develop schedulers which are suitable for thousands of Unikernel VMs on a single host. The Credit2 scheduler is the current work which facilitates masses of Unikernels (as well as other workloads), but Xen Project's flexibility in this area makes it possible to develop new schedulers as Unikernel adoption progresses.
  • Education: The Xen Project continues to organize educational events for potential users of Unikernels, including 2016 Unikernels and More: Cloud Innovators Forum (January 22 at SCALE 14x), 2015 Unikernel User Summit, and 2015 Innovation in the Cloud Conference. We also have written numerous articles and blog posts about the use and concepts around Unikernels.

Unikernel List

The following Unikernels are currently of interest to Xen Project users (though this list is not at all exhaustive):


Because of the dynamic state of this technology, this list will likely be in constant flux for the next few years.

References

Retrieved from "https://wiki.xenproject.org/index.php?title=Unikernels&oldid=16045"