Part II Cloud Infrastructure And Virtualization

Chapter 5 Virtualization

Introduction
• The previous chapter describes the basic infrastructure of a data center, including physical infrastructure, such
as power and cooling, as well as racks, pods, servers, networks, and storage facilities.

• This chapter begins the description of virtualization mechanisms and technologies that allow a cloud owner to
use the facilities to provide elastic computing focusing on the concept and support systems of a Virtual Machine.

• The next chapters describe an alternative virtualization technology used in data centers, virtual networks and
virtual storage facilities.

Approaches To Virtualization
• The concept of virtual machines existed long before cloud computing was invented.

• The technologies used to implement virtual machines can be divided into three broad categories:
o Software emulation
▪ Enables programs compiled for one machine to be run via software on another system
which increases the portability of compilers and other apps.
▪ Software emulation incurs significant execution overhead, making it ineligible as a form
of virtualization in a data center.

o Para-virtualization
▪ An early form of virtualization that allows multiple operating systems to run on a
computer at the same time by using special software known as a hypervisor to control the
operating systems.
▪ Unlike software emulation, para-virtualization allows software to run at high speed by
allowing the processor to execute instructions directly with no extra software involved.
We say that para-virtualization allows instructions to execute natively.
▪ Para-virtualization has the advantage of allowing high-speed execution and the
disadvantage of requiring code to be altered to replace privileged instructions before it
can be run.

o Full virtualization
▪ Allows multiple operating systems to run on a single computer at the same time and at
high speed without requiring operating system code to be altered.

Approaches To Virtualization

• The full virtualization technologies currently used to support Virtual Machines (VMs) in cloud data centers have
three key properties:
o Emulation of commercial instruction sets - A VM gives the appearance of being identical to a
conventional computer, including the complete instruction set. Code that has been compiled to run on a
commercial computer will run on a VM unchanged.
o Isolated facilities and operation - Each VM run an operating system at the same time, so from the point
of view of an operating system running on a VM, the operating system thinks it controls all of physical
memory, a set of I/O devices, and the processor, including all cores
o Efficient, low-overhead execution – When an application runs on a VM, most instructions execute as
fast as they do when the application executes directly on the underlying processor.
Conceptual Organization Of VM Systems
• The general idea behind VM is to load software onto a server that allows the cloud provider to create multiple
VMs. And allow the tenant who owns each VM to boot and use an operating system on the VM.

• The key piece of software responsible for creating and managing VMs is known as a hypervisor. Effectively,
the hypervisor can be viewed as controlling the underlying hardware.

• Figure 5.1 illustrates the conceptual organization of a server running hypervisor software, and a set of VMs that
each run an operating system and apps. The figure shows a type 1 hypervisor, commonly used in data centers

VM 1 VM 2 VM N

app 1 app 2 app 3 app 4 app 5 app 6 ... app 7 app 8 app 9

OS 1 OS 2 OS N

hypervisor software

server hardw
a are

Figure 5.1 Illustration of a server running a hypervisor and a set of VMs.

Efficient Execution And Processor Privilege Levels

• To understand how a VM runs apps at hardware speed, consider how an operating system runs apps on a
conventional computer. When a user launches an app, the operating system loads the code for the app into the
computer’s memory. The operating system then instructs the processor to start executing the code. Execution
proceeds at the hardware rate because the processor executes code for the app directly without going “through”
the operating system.

• To prevent vulnerabilities, the processor hardware used in a conventional computer has two privilege levels or
modes of operation.

• Operating system code runs in kernel mode, which allows the operating system to perform all possible
instructions. When it switches the processor to application code, the operating system also changes to user
mode, which means only basic instructions are available.

• If the application makes a system call to request an operating system service (e.g., to read from a file), the
processor transitions back to kernel mode.

OS starts first
OS starts an app
app invokes an
OS service

code in memory operating system code app code

executed in kernel mode executed in user mode

Figure 5.2 Illustration of operating system and app code in memory. The processor executes each at
the same high speed, changing mode when transitioning from one to the other.
 • If an application, which runs in user mode, attempts to make an instruction that requires privilege or attempts,
an illegal memory access, the processor raises an exception, which transfers back to a special point in the
operating system to allow the operating system to handle the problem.

Extending Privilege To A Hypervisor

• When a server runs a hypervisor and VMs, the software uses the same approach as an operating system uses to
run apps, except that the processor employs three levels of privilege: one for the hypervisor, a second for an
operating system, and a third for apps.

• Only the hypervisor can create a VM and allocate memory to the VM. The operating system is restricted to the
memory that has been allocated to its VM. As with a conventional computer, the processor always runs code
directly from memory, allowing the code to be executed at hardware speed.

hypervisor starts first

hypervisor creates a VM and starts an OS

OS starts an app
app invokes an
OS exits OS service

code in memory hypervisor code operating system code app code

executed in hypervisor mode executed in kernel mode executed in user mode

Figure 5.3 Illustration of transitions among code in memory when a hypervisor runs a VM with an
operating system and the operating system runs an app.

Levels of Trust
• We can think of the three processor modes as imposing three levels of trust:
o In hypervisor mode, the processor can perform any operation available on the hardware so the hypervisor
code is trusted completely.
o In kernel mode, the processor restricts the set of operations to ensure that the operating system cannot
affect other VMs or the hypervisor, so the operating system code does not need to be trusted as much as
hypervisor code.
o In user mode, the processor restricts the set of operations, making it impossible for an app to affect
other apps or the operating system so an app does not need to be trusted as much as an operating system.

Levels of Trust and I/O Devices

• On a conventional computer, the operating system uses a hardware mechanism known as a bus to communicate
with I/O devices. The first step consists of sending a series of requests across the bus to form a list of all I/O
devices that are present. The operating system must include device driver software for each device.

• Each virtual machine runs its own operating system, and a virtual machine can boot a standard operating
system, but the hypervisor cannot allow one of the operating systems to gain exclusive control of I/O devices
because the devices must be usable by all virtual machines.

Virtual I/O Devices

• When it creates a VM, a hypervisor creates a set of virtual I/O devices that are implemented by software for
the VM to use.

• When an operating system on a VM attempts to use the bus to access an I/O device, the access violates privilege,
which means the hypervisor is invoked. The hypervisor runs the appropriate virtual device software, and
then arranges to send the response to the operating system as if a physical device responded.
 • From an operating system’s point of view, a virtual device is indistinguishable from a real device because
communication with a virtual device uses the same bus operations that communication with a physical device
uses.

Virtual Device Details

• The use of virtual devices introduces two approaches, and both have been used:

o Invent a new, imaginary device - Allows a programmer to create a virtual device with clean design that
avoids the messy hardware details, making it much easier to write device driver software. It may also
be possible to increase efficiency (e.g., by creating an imaginary disk with large blocks).

o Emulate an existing hardware device - Involves creating an imaginary device consisting of software
that emulates an existing hardware device.

• Because the device driver software used with one operating system is incompatible with other operating systems,
creating a new, imaginary device requires that a separate driver be created for each operating system.

• Building virtual device software that emulates an existing hardware device avoids having to build new device
drivers — an operating system can load and run existing device driver software.

• The downside of building a virtual device that emulates an existing hardware device arises because the virtual
device must behave exactly like a real hardware device. It must accept all the same requests and respond to
each request exactly like the hardware device responds.

An Example Virtual Device

• As an example of a virtual device, consider a virtual disk. Because data centers locate storage facilities separate
from servers, all disk I/O requires communication over the data center network. Virtual disk software handles
the situation easily by providing a standard disk interface to an operating system and also communicating over
the network.

• The virtual disk code occupies a position between an operating system that runs in a VM and the network code
in the hypervisor.

VM

operating system

virtual disk emulates a hardware device

virtual disk

virtual disk uses the network

data center
storage
data center
network code
network

Figure 5.4 The conceptual organization of an operating system, virtual disk code, and network
code.
 • Each time it receives a request, the virtual disk code uses the network to communicate with the storage facility
in the data center. The virtual disk specifies the VM that made a request, and either sends data to be stored on
the VM’s disk or requests a copy of data from the VM’s disk.

A VM As A Digital Object
• Because a VM is created and managed entirely by software, all the pieces of a VM can be collected
together into a digital object.

• A hypervisor must keep a record of each VM, the region(s) of memory that have been allocated to each
VM, the virtual I/O devices that have been created for each VM (including disk space that has been allocated in
the data center storage facility), and the current status of each VM (e.g., whether the VM is currently running or
has been suspended to allow another VM to run).

• The code, data, and apps that each VM is running are all stored in memory, so when the VM’s memory has
been collected, the OS and apps will be collected. This also includes the virtual devices that have been created
for the VM since they are software as well.

VM Migration
• Virtual migration involves a hypervisor stopping a VM that is running on one server, converting the VM to a
digital object, sending the bytes across the network to a new server, and then a receiving hypervisor resuming
the VM on the new server.

• The ability to migrate VMs allows a provider to rebalance loads dynamically to eliminate hot spots.

• Migration has many other uses. For example:

o During periods of especially light load, a data center manager can migrate VMs away from an area of
servers and then power down the empty servers to reduce power consumption.
o A set of VMs owned by a given customer can be migrated to the same pod (or adjacent pods), reducing
the network traffic that must cross the data center and reducing the latency among the customer’s VMs.

Live Migration Using Three Phases

• Instead of stopping a VM, engineers have devised a migration scheme that allows live migration.

• To enable live migration, the amount of time a VM is unavailable must be minimized. The technique used
divides migration into three phases:
o Phase 1: pre-copy –The entire memory of the VM is copied to the new server while the VM continues to
run. Pages in memory that change during this phase are handled in the next phase.

o Phase 2: stop-and-copy - The VM is temporarily suspended, and any pages that changed after the phase 1
copy are copied again. The virtual memory system on modern servers makes it easy to detect which
pages have been changed (i.e., are dirty).

o Phase 3: post-copy - The old hypervisor sends t he remaining state information to the hypervisor on the
new server. The state information includes items that are needed to unsuspend the VM, including the
contents of registers when the VM was suspended. The hypervisor on the new server uses the
information to allow the VM to continue executing.
Running Virtual Machines In An Application
• An alternative form of VM technology has been developed that allows a hypervisor to run on a conventional
operating system whereby a user launches a hypervisor application called a hosted hypervisor. A hosted
hypervisor runs along with other applications. Once it starts, the hosted hypervisor allows a user to create and
manipulate VMs.

• When the user launches a hosted hypervisor, the hypervisor runs as an application process and runs in user space.

• Each VM must run an operating system, which is called a guest operating system. A guest operating system
does not need to be the same as a host operating system, and guest operating systems may differ from one another.

VM 1 VM 2
apps on VM 1 apps on VM 2

other apps running on

the user’s computer
guest OS 1 guest OS 2

hosted hypervisor

host operating system (user’s main operating system)

computer hardware

Figure 5.5 The conceptual arrangement of software on a conventional computer that results when a
user runs a hypervisor application and creates two VMs.

Three questions that arise (and will be addressed in this chapter as well a future chapter) concerning a system that runs a
hosted hypervisor on a conventional computer that runs directly on server hardware.

• How is it possible?
• What benefit does it offer a user?
• Is the technology useful in a cloud data center?

Facilities That Make A Hosted Hypervisor Possible

• Two facilities allow a hosted hypervisor and a guest OS to operate correctly without high privilege: a
processor mechanism that supports virtualization and a way to map guest OS operations onto the host operating
system’s services.

• Modern processors include a special virtualization mechanism that enables a hosted hypervisor to create VMs
that each run a guest OS. The mechanism allows a guest OS to proceed as if it were running at the highest
privilege level, even though it does not have privilege and does not have complete access to the underlying
hardware.

• A hosted hypervisor arranges a mapping between I/O requests that a guest OS makes and services in the host
operating system.

• Because a hosted hypervisor can map I/O requests from a guest operating system onto services offered by the
host operating system, it is possible for applications running on VMs and applications running on the host to
share files.
How A User Benefits From A Hosted Hypervisor
• A hosted hypervisor allows a user to run multiple operating systems on a single computer.

• Multiboot mechanisms also allow a user to boot multiple operating systems, but a user can only boot one system
at a given time.

• Alternately, a hosted hypervisor allows a user to run multiple operating systems simultaneously and switch
among them quickly without having to reboot the computer.

Summary

• Cloud data centers make extensive use of Virtual Machine (VM) technology.

• Software known as a hypervisor allows a user to create and manage VMs. Conceptually, the hypervisor owns
the underlying hardware, VMs run over the hypervisor, and each VM runs an operating system plus apps.

• Providing levels of privilege imposes a hierarchy of trust.

• A hypervisor provides each operating system with the illusion that it has direct access to peripheral devices over
a conventional I/O bus.

• All pieces of a VM can be collected into a digital object, which can be sent over a network, allowing hypervisors
to migrate a VM from one physical server to another.

• An alternative form of VM technology allows a user to run a hosted hypervisor on a conventional computer
giving he user he ability to switch among operating systems without rebooting the computer.