Xen - Introduction

In 2003 a team of researchers at the University of Cambridge released the world's most advanced hypervisor: Xen. At first, the team developed a multimedia operating system called 'Nemesis'. This introduced the seed of what would become Xen: it had a domain switcher, which was a very low-level, very thin virtual machine layer that provided resource guarantees to the domains above it. Later, the developers needed a VMM that would provide strong resource isolation between users running VMs on the physical machine, and most importantly, would provide isolation without a noticeable drop in performance. Having failed to find anything that came close to their criteria, they built their own.

Xen is an Open-Source hypervisor that creates and manages domains for multiple virtual machines. It uses paravirtualization, where the guest operating systems are aware that they are running in a virtualized environment. With paravirtualization, the guest operating system is modified to make special calls (hypercalls) to the hypervisor for privileged operations, instead of the regular system calls in a traditional unmodified operating system. The applications in the guest operating system’s domain, however, remain unmodified.

Xen lies between the hardware and the operating system allowing multiple virtual machines to run simultaneously on a single physical system. Xen does not support any devices natively. Instead, it provides a mechanism by which a guest operating system can be given direct access to a physical device. Thus, the guest operating system can use an existing device driver. By separating the guests from the hardware, the Xen hypervisor is able to run multiple operating systems securely and independently.

(Figure 1 - A basic  Xen Configuration)

As mentioned before, Xen provides an environment where multiple guest operating systems can run. Each gust runs inside its own environment called ‘domain’. In Xen not all quests are created equal, one in particular is significantly more equal than the others. This one which is called Domain0 (dom0) is the first guest to run when the physical system boots and has elevated privileges. On the other hand, the other domains are referred as DomainU (domU) (Figure 1).

Domain0 is very important to a Xen system. Xen itself doesn’t include any device drivers. All device drivers are provided and handled by Domain0 which runs at a higher privilege level than the other guests and thus can access the hardware. Except from accessing the hardware, Domain0 is also responsible for handling administrative tasks, for example starting and stopping domU guests. We can say that Domain0 provides the user interface to the Xen hypervisor. For security reasons, it is practice to do as little in Domain0 as possible. An exploit on Domain0 can harm the whole system, thus most work should be done in DomainU guests.

DomainU is an unprivileged domain and typically is not allowed to perform any hypercalls that directly access the hardware. Instead, a domU guest implements a front end of some split device drivers. Split device drivers are not normal drivers. Their job is to put the request from the user application into some shared memory. The other half of the split driver which runs on the dom0 guest, reads the request from the shared memory and passes it to the real device driver. Unlike dom0 guests, you can have an arbitrary number of domU guests on a single system.

As mentioned above, all the hardware is controlled in Domain0. However this configuration hides some dangers. Specifically, if a device driver contains bugs, it can crash the Domain0 kernel, which in turn can bring down all the guests. Thus, it’s a good approach to isolate a device driver in its own domain (Figure 2).

(Firgure 2 - Driver isolation in Xen)

Xen has a wealth of features ready for business use. The most popular is the support for fast live migration which enables you to move a virtual machine to a different physical system while it’s still running without having any downtime. Xen is also able to scale to a degree that other virtualization platforms cannot reasonably achieve. Most desktop machines can easily run up to 16 VMs simultaneously, but Xen itself is capable of running 128 VMs or more. Even when running just one VM, Xen excels by providing performance within a couple of percent of equivalent bare hardware.