Virtualizing Resources for the Cloud - Large Scale and Big Data: Processing and Management - page 523

16.8.3 X en ' s a PProaCh to i/o v irtualization
As a concrete example, we discuss Xen's approach to I/O virtualization. As we pointed
out earlier, to get around the problem of having device drivers for the hypervisor as
well as the guest OSs, Xen co-locates its hypervisor with a traditional general-purpose
OS. Figure 16.24 shows a host OS and the Xen hypervisor executing in full privileges
at ring 0. In contrary, guest OSs run unprivileged at ring 1, while all processes at all
domains (i.e., virtual machines) run unprivileged at ring 3, assuming a system with
four rings (e.g., Intel-32). On systems with only two levels of privileges, the hypervisor
and the host OS can execute in system mode, while domains and processes can execute
in user mode. As illustrated in the figure, Xen eliminates the device drivers entirely
from guest OSs and provides a direct communication between guest OSs at domain U i
and the host OS at domain 0 [21]. More precisely, every domain U i in Xen will exclude
virtual I/O devices and relevant drivers. I/O requests will accordingly be transferred
directly to domain 0, which by default hosts all the required device drivers necessary
to satisfy any I/O request. For instance, rather than using a device driver to control a
virtual Network Card Interface (vNIC), with Xen, network frames/packets are trans-
mitted back and forth via event channels between domain U i and domain 0, using NIC
front-end and back-end interfaces, respectively (see Figure 16.24). Likewise, no virtual
disk is exposed to any guest OS and all disk data blocks incurred by file reads and
writes are delegated by the Xen hypervisor to domain 0.
16.8.4 a t aXonomy oF v irtualization s uites
To this end, we briefly survey some of the current and common virtualization software
suites. We distinguish between virtualization suites and hypervisors; many vendors often
use these terms interchangeably. As discussed throughout this chapter, a hypervisor is
mainly responsible for running multiple virtual machines (VMs) on a single physical
host. On the other hand, a virtualization suite comprises of various software compo-
nents and individual hypervisors that enable the management of many physical hosts and
VMs. A management component typically issues commands to the hypervisor to create,
destroy, manage, and migrate VMs across multiple physical hosts. Table 16.2 shows our
taxonomy of four virtualization suites, vSphere 5.1 [59], Hyper-V [43], XenServer 6 [17],
and RHEV 3 [50]. We compare the suites in terms of multiple features including the
involved hypervisor, the virtualization type, the allowable maximum number of vCPUs
per a VM, the allowable maximum memory size per a VM, and whether memory over-
commitment, page sharing, and live migration are supported. In addition, we indicate
whether the involved hypervisors contain device drivers, and list some of the popular
cloud vendors that utilize such hypervisors. To elaborate on some of the features, live
migration allows VMs to be seamlessly shifted from one VM to another. It enables many
management features like maintenance, power-efficient dynamic server consolidation,
and workload balancing, among others. Page Sharing refers to sharing identical memory
pages across VMs. This renders effective when VMs use similar OS instances. Lastly,
some hypervisors eliminate entirely device drivers at guest OSs and provide direct com-
munications between guest OSs and host OSs co-located with hypervisors (similar to
what we discussed in Section 16.8.3 about the Xen hypervisor).