Theory of Virtualization

BY
Naveen Kumar
Syllabus and Reference Books
THEORY OF VIRTUALIZATION (CS-1844)
UNIT 1: Introduction, Overview of virtualization 8(L)
UNIT 2: Hardware/Server virtualization 8(L)
UNIT 3: Network virtualization 8(L)
UNIT 4: Virtual machines 6(L)

Text/Reference Books:

Virtual Machines: Versatile Platforms for Systems and Processes by James E. Smith,
Ravi Nair,
Virtualization: From the Desktop to the Enterprise by Chris Wolf, Erick M. Halter
Network virtualization by Kumar Reddy, Victor Moreno,
Advanced Server Virtualization: VMware and Microsoft Platform in the Virtual Data
Center by David Marshall, Wade A. Reynolds
Why Virtualization?
• The key to managing the complexity in the computer system is their
division into levels of abstraction separated by well defined
interfaces.
• Well defined interfaces allow computer design tasks to be decoupled
so that teams of hardware and software designers can work
independently.
• AMD develops microprocessors that implement the Intel IA-32
instruction set, while software engineers at Microsoft develop
compliers that map high level languages to the same instruction set.
• Subsystems and components designed to the specifications for one
interface will not work with those designed for another– This is the
major drawback of well defined interfaces.
What is Virtualization and Virtual Machine?
• Virtualization provides a way of relaxing the foregoing constraints and
increasing flexibility.
• When a system (or subsystem), e.g., a processor, memory, or I/O device, is
virtualized, its interface and all resources visible through the interface are
mapped onto the interface and resources of a real system actually
implementing it.
• Virtualization differs from abstraction as the virtualization does not
necessarily hide details; the level of detail in a virtual system is often the
same as that in the underlying real system.
• A virtual machine (VM) is implemented by adding a layer of software to a
real machine to support the desired virtual machine's architecture.
• For example, virtualizing software installed on an Apple Macintosh can
provide a Windows/IA-32 virtual machine capable of running PC
application programs.
 Computer System Architecture

Instruction Set Architecture (ISA): (7) user ISA &

(8) user ISA and the system ISA.
Application Binary Interface (ABI): (3) & (7)
System Call: (3)
Application Programing Interface (API): (2) & (7)

Figure-1
ABI vs API
• ABI is an interface between two binary program modules.
• Often, one of these modules is a library or operating system facility, and
the other is a program that is being run by a user.
• An ABI defines how data structures or computational routines are accessed
in machine code, which is a low-level, hardware-dependent format.
• In contrast, an API defines this access in source code, which is a relatively
high-level, hardware-independent, often human-readable format.
• Adhering to an ABI is usually the job of a compiler, operating system, or
library author; however, an application programmer may have to deal with
an ABI directly when writing a program in a mix of programming languages.
 Machine Interfaces

(a) (b)
Machine Interfaces. (a) Application binary interface (ABI); (b) instruction set architecture (ISA) interface.
Figure-2
The process of virtualization consists of two parts:
1. The mapping of virtual resources or state,
e.g., registers, memory, or files, to real resources in the
underlying machine
2. The use of real machine instructions and/or system
calls to carry out the actions specified by virtual
machine instructions and/or system calls,
e.g., emulation of the virtual machine ABI or ISA.
 Types of Virtual Machine

1. Process Virtual Machine (over ABI)

2. System Virtual Machine (over ISA)
 Process VM
• A process virtual machine is capable of supporting an individual
process.
• In process VMs, the virtualizing software is placed at the ABI interface,
on top of the OS/hardware combination.
• The virtualizing software emulates both user-level instructions and
operating system calls.

Figure-3
 System Virtual Machine
• A system virtual machine provides a complete system environment.
• This environment can support an operating system along with its
potentially many user processes.
• It provides a guest operating system with access to underlying
hardware resources, including networking, I/O, and, on the desktop,
a display and graphical user interface.

Figure-4
The process VMs can provide replication, emulation, and
optimization. Various implementation of system VM are:
1. Multiprogramming
2. Emulators and Dynamic Binary Translators
3. Same-ISA Binary Optimizers
4. High-Level Language Virtual Machines: Platform
Independence
 Process VM: Multiprogramming
• The first and most common virtual machine is the combination of the
OS call interface and the user instruction set forms the machine that
executes a user process.
• Most operating systems can simultaneously support multiple user
processes through multiprogramming, where each user process is
given the illusion of having a complete machine to itself.
• Each process is given its own address space and is given access to a
file structure.
• The operating system timeshares the hardware and manages
underlying resources to make this possible.
• In effect, the operating system provides a replicated process-level
virtual machine for each of the concurrently executing applications.
 Process VM: Emulators and Dynamic Binary
•
Translators
A more challenging problem for process-level virtual
machines is to support program binaries compiled to
a different instruction set than the one executed by
the host's hardware, i.e., to emulate one instruction
set on hardware designed for another.
• FX!32 is a software emulator program that allows
Win32 programs built for the Intel x86 instruction set
to execute on DEC Alpha-based systems running
Windows NT. Figure-5
• Two ways
1. Interpretation.
2. Binary translation
Interpretation
• An interpreter program executing the target ISA fetches, decodes, and emulates the
execution of individual source instructions.
• This can be a relatively slow process, requiring tens of native target instructions for
each source instruction interpreted.

Binary Translation
• For better performance, binary translation is typically used.
• With binary translation, blocks of source instructions are converted to target
instructions that perform equivalent functions.
• There can be a relatively high overhead associated with the translation process, but
once a block of instructions is translated, the translated instructions can be cached
and repeatedly executed much faster than they can be interpreted.
• Because binary translation is the most important feature of this type of process
virtual machine, they are sometimes called dynamic binary translators.
 Process VM: Same-ISA Binary Optimizers
• Same-lSA dynamic binary optimizers are implemented in a manner very similar to
emulating virtual machines, including staged optimization and software caching of
optimized code.
• Same-ISA dynamic binary optimizers are most effective for source binaries that are
relatively optimized to begin with, a situation that is fairly common in practice.
• A dynamic binary optimizer can collect a profile and then use this profile information to
optimize the binary code on the fly.
• An example of such a same-ISA dynamic binary optimizer is the Dynamo system,
originally developed as a research project at Hewlett-Packard [1].
Process VM: High-Level Language Virtual Machines
(Cont’d)
• VMs described earlier, allows cross-platform compatibility only on a case-by-
case basis and requires a great deal of programming effort.
• For example, if one wanted to run IA-32 binaries on a number of hardware
platforms currently in use, e.g., SPARC, PowerPC, and MIPS, then an FX!32-
1ike VM would have to be developed for each of them.
• Full cross-platform portability is more easily achieved by taking a step back
and designing it into an overall software framework.
• One way of accomplishing this is to design a process-level VM at the same
time as an application development environment is being defined.
• Here, the VM is designed for ease of portability and to match the features of
a high-level language (HLL) used for application program development.
• These VMs are focused on minimizing hardware-specific and OS-specific
features because these would compromise platform independence.
 Process VM: High-Level Language Virtual Machines
• The Sun Microsystems Java VM architecture and
the Microsoft common language infrastructure
(CLI), which is the foundation of the .NET
framework, are more recent, widely used
examples of HLL VMs.
• The ISAs in both systems are based on bytecodes;
that is, instructions are encoded as a sequence of
bytes, where each byte is an opcode, a single-byte
operand, or part of a multibyte operand.
• These bytecode instruction sets are stack based
(to eliminate register requirements) and have an
abstract data specification and memory model.
• In fact, the memory size is conceptually
unbounded, with garbage collection as an
assumed part of the implementation.
• Because all hardware platforms are potential
targets for executing Java- or CLI-based programs,
applications are not compiled for a specific OS.
• Rather, a set of standard libraries is provided as
part of the overall execution environment.
Figure-6
 System Virtual Machine (Cont’d)
• System VM provide an environment in which many processes belonging to
multiple users can coexist.
• They were first developed in 1960s and early 1970s.
• At that time the computers were very expensive so there is a need to share them
between multiple users.
• Different groups of users sometimes wanted different operating systems, the
system VMs allows them to do so.
• Over time, as hardware became much less expensive and much of it migrated to
the desktop, interest in these classic system VMs faded.
 System Virtual Machine
• Today, system VMs becomes popular again.
• The large, expensive mainframe systems are now servers or server farms, and these
servers may be shared by a number of users or user groups.
• Perhaps the most important feature of today's system VMs is that they provide a
secure way of partitioning major software systems that run concurrently on the same
hardware platform.
• Software running on one guest system is isolated from software running on other
guest systems.
• The ability to support different operating systems simultaneously, e.g., Windows and
Linux is another reason for their appeal, although it is probably of secondary
importance to most users.
Various implementation of system VM are:
1. Classic System VMs
2. Hosted VMs
3. Whole System VMs
4. Codesigned VMs
System VM: Classic System VMs (Cont’d)
• The classic approach to system VM architecture is given by Popek and Goldberg
[2] in 1974 is shown in Figure.
• The VMM is first placed on bare hardware, and virtual machines fit on top.
• The VMM runs in the most highly privileged mode, while all the guests systems
run with lesser privileges.
• This system VM architecture is the most efficient, and it provides service to all the
guest systems in a more or less equivalent way.
• One disadvantage of this type of system, at least for desktop users, is that
installation requires wiping an existing system clean and starting from scratch,
first installing the VMM and then installing guest operating systems on top.
• Another disadvantage is that I/O device drivers must be available for installation
in the VMM, because it is the VMM that interacts directly with I/O devices.
System VM: Classic System VMs

Figure-7
System VM: Hosted VMs
• An alternative system VMM implementation builds virtualizing software on
top of an existing host operating system ~ resulting in what is called a
hosted VM.
• With a hosted VM, the installation process is similar to installing a typical
application program. Furthermore, virtualizing software can rely on the
host OS to provide device drivers and other lower-level services; they don't
have to be provided by the VMM.
• The disadvantage of this approach is that there can be some loss of
efficiency because more layers of software become involved when OS
service is required.
• The hosted VM approach is taken in the VMware implementation (VMware
2000), a modern system VM that runs on IA-32 hardware platforms.
System VM: Whole System VMs (Emulation)
(Cont’d)
• In the conventional system VMs described earlier, all the system software
(both guest and host) and application software use the same ISA as the
underlying hardware.
• In some important situations, however, the host and guest systems do not
have a common ISA.
• For example, the Apple PowerPC-based systems and Windows PCs use
different ISAs (and different operating systems), and they are the two most
popular desktop systems today.
• Because software systems are so closely tied to hardware systems, this may
require purchase of multiple platform types, even when unnecessary for
any other reason, which complicates software support and/or restricts the
availability of useful software packages to users.
System VM: Whole System VMs (Cont’d)
• This situation motivates system VMs, where a complete software
system, both OS and applications, is supported on a host system that
runs a different ISA and OS.
• These are called whole-system VMs because they essentially virtualize
all software.
• Because the ISAs are different, both application and OS code require
emulation, e.g., via binary translation.
• For whole-system VMs, the most common implementation method is
to place the VMM and guest software on top of a conventional host
OS running on the hardware.
 System VM: Whole System VMs
• Figure 8 illustrates a whole-system VM built on top of a
conventional system with its own OS and application
programs.
• An example of this type of VM is Virtual PC [3], which
enables a Windows system to run on a Macintosh
platform.
• The VM software executes as an application program
supported by the host OS and uses no system ISA
operations.
• It is as if the VM software, the guest OS, and guest
application(s) are one very large application
implemented on the host OS and hardware.
• Meanwhile the host OS can also continue to run
applications compiled for the native ISA; this feature is Figure-8
illustrated in the right-hand section of the drawing.
System VM: Codesigned VMs (Hardware Optimization)
• In all the VM models the goal has been functionality and portability either to
support multiple (possibly different) operating systems on the same host
platform or to support different ISAs and operating systems on the same
platform.
• In practice, these virtual machines are implemented on hardware already
developed for some standard ISA and for which native (host) applications,
libraries, and operating systems already exist.
• Yet now, improved performance (i.e., going beyond native platform performance)
has not been a goal- in fact minimizing performance losses is often the
performance goal.
• Codesigned VMs are designed to enable innovative ISAs and/or hardware
implementations for improved performance, power efficiency, or both.
System VM: Codesigned VMs (Cont’d)
• The host's ISA may be completely new, or it may be based on an existing ISA with
some new instructions added and/or some instructions deleted.
• In a codesigned VM, there are no native ISA applications.
• It is as if the VM software is, in fact, part of the hardware implementation.
• Because the goal is to provide a VM platform that looks exactly like a native
hardware platform, the software portion of a codesigned VM uses a region of
memory that is not visible to any application or system software.
• This concealed memory is carved out of real memory at boot time and the
conventional guest software is never informed of its existence.
• VMM code that resides in the c practically any time and perform a number of
different functions.
System VM: Codesigned VMs
• In its more general form, the VM software includes a binary translator that
converts guest instructions into native ISA instructions and caches the translated
instructions in a region of concealed memory.
• Hence, the guest ISA never directly executes on the hardware. Of course,
interpretation can also be used to supplement binary translation, depending on
performance tradeoffs.
• To provide improved performance, translation is coupled with code optimization.
• Optimization of frequently executed code sequences is performed at translation
time, and/or it is performed as an ongoing process while the program runs.
• Perhaps the best-known example of a codesigned VM is the Transmeta Crusoe
[4].
VM Taxonomy

Figure-9
References
[1] Bala, V., E. Duesterwald, and S. Banerjia. 2000. Dynamo" A Transparent Dynamic Optimization System, Proc. A CM SIGPLAN Conf.
Programming Language Design and Implementation (June), pp. 1-12.
[2] Popek, G. J. and R. P. Goldberg. 1974. Formal Requirements for Virtualizable Third-Generation Architectures, Communications of
the A CM (July), pp. 412-421.
[3] Traut, E. 1997. Building the Virtual PC, Byte (November), pp. 51-52.
[4] Halfhill, T. R. 2000. Transmeta Breaks x86 Low-Power Barrier, Microprocessor Report (February 14), pp. 9-18.
 Some Links
x86 Architecture
• https://en.wikipedia.org/wiki/X86_instruction_listings

List of System Calls

• http://asm.sourceforge.net/syscall.html

Building your own Hypervisor

• https://rayanfam.com/topics/hypervisor-from-scratch-part-1/