Xen Virtualization and Cloud Computing #05: The Xen Project, Unikernels, and the Future
Previous articles in this series introduced virtualization, described how Xen achieves it through its architecture and key features, and described other platforms with which Xen interacts. This article wraps up the series by describing some exciting advances in virtualization and how Xen supports them.
As we’ve seen, a hypervisor loads a VM that holds a complete operating system such as GNU/Linux, Windows, or BSD. The VM must be complex and large because it is essentially a whole computer system. By default, the operating system in a VM supports a wide range of hardware from many vendors with different design and drivers. These regular operating systems are also multi-user, multi-process, and multi-purpose, adding to their size.
To run an application without the bulk of extra software it doesn’t need, the concept of a unikernel was developed. A unikernel is single-purpose (usually) and is created to run in a VM or container instead of directly on hardware, so it is free of the complexity of device drivers. A unikernel is not multi-user or multi-process, but just creates a single thread of code that runs one application. It can be compiled with just the libraries it needs. Therefore, a unikernel is small, lightweight, and quick to load and run. But it runs only in a VM or container.
In a very broad sense, a unikernel reproduces the simple execution environment of mainframes in the era before multi-user operating systems. It is also reminiscent of two projects from the late 1990s, MIT’s Exokernel and Nemesis, which was developed by Citrix along with several universities.
Basic architecture of a unikernel
A unikernel generates a singular runtime environment that lacks a shell, can’t spawn subprocesses, and can’t create multiple threads. Developers select the minimal set of libraries that required for their application to run. These libraries are then compiled with the application and make an executable image (the unikernel) that can be executed directly on a hypervisor without a complete operating system such as GNU/Linux or Windows OS. The unikernel is considered a VM from the point of view of the hypervisor. You can also think of a unikernel as a pure runtime for programming languages. Unikernels exist for Ocaml, Erlang, Java, Haskell, Rust, Ruby, Go, an other languages.
The Xen Project is a leader in the birth of Unikernels. This technology has perhaps become the core of a new form of cloud computing, where a hypervisor can support many VMs.
Figure 7 shows the components required to run a unikernel.
I explained earlier that the advantage of containers is their speed and small size. These features were notable reasons for using containers before the advent of unikernels. In fact, unikernels tend to beat the containers for speed and size. They also have excellent security because they contain no extra components where vulnerabilities might lurk. Boot times are nearly instantaneous.
From the features just listed, security is the most important. The unikernels, because of the lack of functions that a standard operating system provides, have a smaller attack surface. There are no shells, no utilities, and no other programs that an intruder can exploit to gain access to the system.
Most unikernels compile into applications, each of which has a unique footprint because of its unique combination of code and library functions. Thus, even if an intruder finds an attack vector into a unikernel, it won’t work with other unikernels.
Figure 8 shows the components of a standard Linux kernel. A unikernel removes the traditional operating system layers, leaving only the minimal necessary system libraries, the programming language runtime, and the application code itself.
The Xen Project as a leader provides a number of capabilities to Unikernel lovers. I will examine some of them here.
As said before, unikernels focus on small and fast packages. In Paravirtualization (PV), Xen Project can give access to the underlying hardware layer to Unikernels. But the hypervisor still contains the actual drivers for the hardware, so they don’t have to be re-implemented in the unikernels. However, unikernels are free to use HVM mode and implement actual hardware drivers.
The security is in the Xen Project hypervisor DNA and it means the smaller attack surface. This feature is in line with Unikernels.
Performance and security are very important for both the Xen Project and unikernels. The bare-metal structure of the Xen hypervisor provides a good platform for many unikernel VMs on a single host.
Some unikernel projects include:
Unikraft: a new development process for unikernels
With all good features unikernels offer, they have some drawbacks. Unikernels force developers to port applications manually to the underlying minimalistic OS and custom-build the list oflibraries used. Think about a big project like Apache, MariaDB, or Suricata-IDS. As you can guess, this requires a lot of effort by experts and considerable amount of time. What is the solution? Do these developers have to sacrifice the high performance of unikernels and stick to a standard OS?
The goal of the Unikraft project is to solve this problem and provide a highly configurable unikernel code base. Another goal is to encourage developers to supply their code in libraries rather than working on independent projects. Unikraft is hoping to create a community around minimalistic OSes and provide a tool that can automatically build this kind of operating systems.
Already, a small operating system kernel called Mini-OS is included with the Xen hypervisor. It is the root of many unikernel projects because it has the kernel drivers for the Xen hypervisor. But the Unikraft project’s goals differ from those of Mini-OS.
Unikraft is at an early stage. According to the NEC Lab, the its anticipated features are:
- Fast boot and migration time
- Low memory footprint
- Strong security
- High density
- High performance
- Developer-friendly tools and processes
- Ability to run on all major platforms
At the time of writing this article, the Unikraft projects are:
- LightVM
- Jitsu
- ClickOS
- Elastic CDNs
LightVM
LightVM is a virtualization solution based on Xen that offers fast boot-times for VMs even when hosting a large number of them. LightVM does this by replacing the Xenstore configuration database with a new distributed solution called NoXS (no Xenstore). NoXS reduces the speed of accessing the database by providing a shared page for each device that contains all the information needed for device initialization. LightVM also using the new Chaos toolstack that does operations like instantiation, migration, saving, and restoring. Currently, LightVM relies on the Linux kernel for Dom0, but for DomU it can use both Linux and Mini-OS based guests. LightVM can boot a VM in 2.3ms, which is twice as fast as Docker. With LightVM you can say, “My VM is both lighter and safer than your Container.”
MirageOS
MirageOS is a library providing operating system functionality. It is used to create Unikernels that provide secure, high-performance network applications for cloud computing and mobile platforms. The main programming language for MirageOS is Ocaml, a high-level programming language with optional functional and object-oriented features, able to create secure and high-performance programs. You can develop your program on your PC by Ocaml and then compile it into a fully-standalone program for Unikernel. There are now more than 100 MirageOS libraries, and MirageOS offers a lot of low-level implementations of the most common protocols, such as TCP/IP, UDP, IPV6, UDPV6, ICMP, DNS, SSH, VNC, HTTP, XMPP, and the Xen Device Drivers. MirageOS help you run your servers more cheaply, securely, and faster in any Xen based cloud.
Other aspects of the Xen Project and its future
The Xen Project is always working to support new hardware and technologies. Some of its current efforts are targettng AMD EPYC CPUs, the Hygon Dhyana 18h processor family, the Raspberry Pi4, and Intel’s AVX512.
If you believe that open source changed the world of software, you should look forward to what RISC-V, pronounced “Risk-Five,” could do for the world of microprocessors. RISC-V is based on the RISC (Reduced Instruction Set Computer) principle. It is too soon to judge the future of RISC-V. At the time of writing this article, RISC-V had some logistical problems, including a lack of a certification process, no standardization for part families or packaging, and no plug-and-play at any point of the hardware or software stacks. Some operating systems, including GNU/Linux and FreeBSD, are being ported to RISC-V architecture. The Xen Project is working on a port too.
The embedded and automotive areas provide good news about the Xen Project too. Several companies, including EPAM, Xilinx, and GlobalLogic are working on Xen for embedded devices in order to change the world of vehicles.
All vehicles nowadays rely on computers, and they usually now control most parts of a car. Some of these parts are sensitive, and security is a big concern in this area. Components such as engine control, autonomous driving, networks, warning lights, speed display, and the fuel tank are vital and must be protected.
Nowadays, most cars use variants of Android, but this OS is not fast and secure enough for such a purpose. More important, some of the car options need an Internet connection, which opens a door for attacks. If an attacker penetrates the car’s computer, they can play with the lives of the driver and others.
The Xen Project provides good security and performance. With a car computer running a Xen hypervisor, the car operating system can launch in the millisecond and Xen can provide a good security by isolation. In these cars, the operating system runs as a DomU under the control of the Xen hypervisor. For more information about this field, you can read “Automotive Virtualization by Xen” on the EPAM company website and “Virtual Open Systems: Automotive mixed-critical virtualization done right” on the Arm company website.
The Xen Project is active in the unikernel area, working to support new technologies and hardware.
Contributing to Xen
If you want to work with the Xen Project, join one or more of its mailing lists, which are quite active. You can send the basic questions about the Xen hypervisor to xen-users@lists.xenproject.org, and questions about its development to xen-devel@lists.xenproject.org.
To help test and debug the Xen Project, please look at our Xen Project Test Days page.
I have written a book about the Xen Project under the name “Hello Xen Project”. It is open source, so anyone can edit and add more chapters to it. I hope that, in the future I can add more chapters to it as well.
About Mohsen Mostafa Jokar:
