Supporting Software - Expert Consolidation in Oracle Database 12c - page 121

Introduction to the Xen Hypervisor
The Xen hypervisor is the result of a research project of the University of Cambridge. As a type 1 hypervisor, it does not
require any operating system to run, it rather starts on bare metal. Although available in many commercial offerings,
the core of Xen is a true open source solution to run all kinds of workloads, including Amazon's Elastic Compute
Cloud. Thanks to a lot of development effort, Xen is able to run a large number of operating systems, including Linux,
Solaris, Windows, and even some BSD derivatives.
Xen was different from other virtualization solutions available at the time it was developed. The majority of
virtualization solutions at that time used binary translation to execute multiple copies of operating systems on the same
hardware. This is termed “full virtualization” in Xen. With full virtualization, guests do not require any modification,
and your Windows 2000 CD-ROM could be used to boot virtual hardware almost identically to physical hardware.
Binary translation results in a lot of CPU overhead, since operations of the guest operating system must be
translated by the host and implemented in a way that is safe to operate multiple operating systems at the same time.
In addition to translating CPU instructions, the virtual machine monitor has to also keep track of the memory used
both within the guest and on the host. Finally, some hardware has to be emulated. Before the advent of hardware
assisted virtualization technologies, these three were done in very cleverly engineered software. A penalty often
applied when running virtualized workloads.
Xen, conversely, used a different approach, called para-virtualization , as illustrated in Figure 4-2 . In a
para-virtualized environment, the guest operating systems are aware that they are being virtualized, allowing for
tighter integration with the hypervisor, resulting in better efficiency. For obvious reasons, this requires changes to the
operating system, and it is no surprise that Linux was the most significant Xen-deployed platform.
Figure 4-2. Conceptual view on the Xen architecture with physical- and hardware virtualized machines
The Xen architecture is built around the hypervisor, the control domain, and the user domains. The hypervisor is
a small piece of software governing access to the hardware of the underlying host. The control domain or dom0 in Xen
parlance is a para-virtualized Linux that uses the Xen hypervisor to access the hardware and manages the guests.
One of the biggest benefits offered by Xen's para-virtualization, even more so when it was released, is the area of
I/O operations. The IO devices (“disks”) in a para-virtualized environment merely link to the I/O drivers in the control
domain, eliminating the need to I/O virtualization. However, many other important aspects of the operating system
also benefit from para-virtualization.
Initially, Xen was not developed as part of the mainline Linux kernel, but that has changed. Two distinct pieces
of software are needed to use Xen: the Xen software and changes to the kernel. Before the code merge subsequently
described in more detail, the Xen software-including patches to the kernel had to be applied before a Linux system could
boot as a dom0. Red Hat Linux 5 supports booting a dom0 kernel based on 2.6.18.x, but has abandoned that approach
with the current release, Red Hat Enterprise Linux 6. SuSE Linux has continued to include the patches in their kernels
up to SuSE Linux Enterprise 11. The so-modified kernel was said to be “xenified,” and it was different from the non-xen
kernel. At the same time, efforts were underway to include the Xen patches in the mainline Linux kernel. There were two