Unit_3_Virtualization_and_Cloud_Enabling

Loading views...

Unit 3: Virtualization and Cloud-Enabling Technologies

3.1 Introduction to Virtualization

Virtualization is the creation of a virtual (software-based) version of something that is normally physical — a server, an operating system, a storage device, or a network resource.

Simple Analogy: Think of an apartment building. One physical building (the hardware) is divided into many independent apartments (virtual machines). Each tenant (guest OS) thinks they have their own building, but they actually share the same foundation.

3.1.1 Why Virtualization Became Popular (5 Key Drivers)

#	Driver	Explanation
a	Increased Performance	Modern CPUs are so powerful that a single machine can easily run multiple OSes simultaneously. Resources sit idle without virtualization.
b	Underutilized Hardware	A server running at 10% CPU capacity is wasteful. Virtualization packs multiple workloads onto one machine.
c	Lack of Physical Space	Data centers cannot keep expanding. Server consolidation (many VMs on fewer physical servers) saves space.
d	Greening Initiatives	Fewer physical servers = less electricity consumed + less cooling required = reduced carbon footprint.
e	Rising Administrative Costs	Managing 100 servers is far more expensive than managing 10 servers running 100 VMs.

3.1.2 Historical Milestones

1966 --> BCPL language uses bytecode (first programming-level VM)
1967 --> IBM CP-67: First hardware hypervisor (for IBM System/360)
1979 --> Unix chroot() — first OS-level isolation primitive
1995 --> Sun releases Java (JVM makes PL-level virtualization mainstream)
1999 --> VMware Virtual Platform: first x86 hardware virtualization product
2002 --> Microsoft releases .NET Framework (CLI-based VM)
2003 --> Xen hypervisor released (open-source paravirtualization)
2006 --> Intel VT-x and AMD-V: hardware-assisted virtualization extensions
2008 --> KVM merged into Linux kernel

3.2 Characteristics of a Virtualized Environment

Every virtualized setup has exactly 3 components:

+--------------------------------------------------+
|                    G U E S T                     |
|  (The thing being virtualized: OS + Apps)        |
+--------------------------------------------------+
            |                    ^
            | requests           | results
            v                    |
+--------------------------------------------------+
|           VIRTUALIZATION LAYER                   |
|  (Intercepts, translates, controls all requests) |
+--------------------------------------------------+
            |                    ^
            | actual ops         | real results
            v                    |
+--------------------------------------------------+
|                    H O S T                       |
|  (The real physical hardware and its resources)  |
+--------------------------------------------------+

Component	Role	Example
Guest	The entity that thinks it has real hardware	A Windows 10 OS installed inside VMware
Virtualization Layer	Software that intercepts guest operations and translates them	VMware Workstation, Xen Hypervisor
Host	The real physical machine	A Dell server with an Intel Xeon CPU

3.2.1 Key Properties of Virtualized Environments

1. Increased Security

The virtualization layer acts as a filter. Every instruction from the guest must pass through it before touching the host. This means:

Malicious code inside a guest cannot escape to the host (sandbox).
Example: Java applets downloaded from the Internet run in a sandboxed JVM — they have no direct access to your hard drive or OS.
Hardware VMs (VirtualBox, VMware): the guest file system is completely separate from the host file system by default.

2. Managed Execution (4 Sub-Properties)

Managed Execution
    |
    +-- (a) SHARING:      1 host  --> multiple guests (server consolidation)
    |
    +-- (b) AGGREGATION:  many hosts --> appears as 1 virtual host (cluster mgmt)
    |
    +-- (c) EMULATION:    run software for a DIFFERENT architecture on current HW
    |                     (Example: run ARM apps on an x86 PC via QEMU)
    |
    +-- (d) ISOLATION:    each guest is walled off from every other guest

Sharing Example: A server with 128 GB RAM can host 10 VMs, each thinking they have 12 GB.
Aggregation Example: A cluster of 50 nodes is presented as one giant machine by cluster management software (like SLURM).
Emulation Example: Playing old arcade games (designed for Motorola 68000 CPU) on a modern x86 PC using MAME emulator.
Isolation Example: If VM-1 crashes due to a bug or virus, VM-2, VM-3 remain completely unaffected.

3. Portability

Hardware VM instances = files (.vmdk, .vhd, .qcow2). Copy the file to any compatible hypervisor and the VM runs.
Java programs: "Compile once, run anywhere" — the .class bytecode file runs on any OS that has a JVM.
This enables VM Live Migration: moving a running VM from one physical server to another with near-zero downtime.

3.3 Taxonomy of Virtualization Techniques

VIRTUALIZATION
    |
    +-- Execution Virtualization
    |       |
    |       +-- Hardware Level (System Level)
    |       |       +-- Full Virtualization
    |       |       +-- Paravirtualization
    |       |       +-- Hardware-Assisted Virtualization
    |       |       +-- Partial Virtualization
    |       |
    |       +-- OS Level (Process Level)
    |       |       +-- FreeBSD Jails, Solaris Zones, Linux Containers (LXC)
    |       |
    |       +-- Programming Language Level
    |       |       +-- JVM (Java), CLR (.NET)
    |       |
    |       +-- Application Level
    |               +-- Wine, VMware ThinApp
    |
    +-- Storage Virtualization  (e.g., SAN, LVM, Amazon S3)
    |
    +-- Network Virtualization   (e.g., VPN, VLAN, SDN)

3.4 The Machine Reference Model (ISA / ABI / API)

To understand virtualization at different levels, you must understand the stack of interfaces in a computing system.

+-----------------------------+
|      APPLICATIONS           | <--- User programs
+-----------------------------+
           |   API (Application Programming Interface)
           |   What apps use to call system libraries
+-----------------------------+
|      LIBRARIES / OS         | <--- Operating System (e.g., Linux, Windows)
+-----------------------------+
           |   ABI (Application Binary Interface)
           |   Defines system calls, calling conventions, binary format
+-----------------------------+
|   HARDWARE / CPU            | <--- Physical processor
+-----------------------------+
           |   ISA (Instruction Set Architecture)
           |   The set of real machine instructions (x86, ARM, MIPS)
           |
        [ System ISA ] --> used by OS kernel
        [ User ISA   ] --> used by user-level programs

Interface	Full Name	What It Defines	Who Uses It
ISA	Instruction Set Architecture	Machine instructions, registers, memory, interrupts	OS kernel & hardware engineers
ABI	Application Binary Interface	System calls, binary format, calling conventions	Compilers, OS, device drivers
API	Application Programming Interface	Function calls into libraries/OS	Application developers

Key Insight: Virtualization works by replacing one of these layers with a software emulation. For example, the JVM replaces the ISA — apps talk to the JVM's virtual instruction set, not the real CPU.

3.4.1 Privileged vs. Non-Privileged Instructions

Not all CPU instructions are equal. The CPU enforces security rings:

          .----------------------------------.
          |   Ring 3: User Applications      |  <-- Least privilege
          |----------------------------------|
          |   Ring 2: OS Services            |
          |----------------------------------|
          |   Ring 1: Device Drivers         |
          |----------------------------------|
          |   Ring 0: OS Kernel / Hypervisor |  <-- Most privilege (supervisor mode)
          '----------------------------------'

Instruction Type	Can run in User Mode?	Example
Non-Privileged	YES	Arithmetic (ADD, MUL), floating point, logic
Privileged	NO — causes a TRAP	Modifying CPU registers, I/O operations
Sensitive (Behavior)	Depends on mode	I/O instructions that reveal system state
Sensitive (Control)	Depends on mode	Instructions that alter processor state

The "17 Sensitive Instructions Problem" (x86 Architecture):

The original x86 architecture had 17 sensitive instructions that could be called in user mode without causing a trap.
This broke the hypervisor model — a guest OS could change privileged state without the hypervisor knowing.
Solution: Intel VT-x and AMD-V (2006) redesigned these as privileged instructions, allowing true hardware virtualization.

3.5 Hardware-Level Virtualization (Hypervisors)

3.5.1 Type I vs. Type II Hypervisors

  TYPE I (Bare Metal)                    TYPE II (Hosted)
  +-----------------------+              +-----------------------+
  |   VM1  |  VM2 |  VM3  |              |   VM1  |  VM2 |  VM3  |
  +-----------------------+              +-----------------------+
  |    HYPERVISOR (VMM)   |              |    HYPERVISOR (VMM)   |
  +-----------------------+              +-----------------------+
  |   Physical Hardware   |              |   Host OS (Windows/   |
  +-----------------------+              |   Linux / macOS)      |
                                         +-----------------------+
                                         |   Physical Hardware   |
                                         +-----------------------+
  Examples: Xen, VMware ESXi,            Examples: VMware Workstation,
  Microsoft Hyper-V, KVM                 VirtualBox, Parallels Desktop

Feature	Type I (Bare Metal)	Type II (Hosted)
Runs on	Directly on hardware	On top of a Host OS
Performance	High (no Host OS overhead)	Lower (shares resources with Host OS)
Complexity	More complex to set up	Easy to install like any application
Use Case	Production servers, data centers	Developer workstations, testing
Examples	VMware ESXi, Xen, Hyper-V	VirtualBox, VMware Workstation

3.5.2 Hypervisor Internal Architecture (3 Modules)

         Guest OS sends instruction
                    |
                    v
         +--------------------+
         |   DISPATCHER       |  <--- Entry point. Decides where to route instruction.
         +--------------------+
           /              \
          v                v
  +-----------+      +-----------+
  | ALLOCATOR |      | INTERPRETER|
  +-----------+      +------------+
       |                  |
   Non-sensitive       Privileged/Sensitive
   instructions        instructions
   (change resources)  (trapped and simulated)
       |                  |
       v                  v
   Grants/denies     Executes the instruction
   resources to VM   in a safe, controlled way

Detailed Module Explanations:

① DISPATCHER:

Acts like a traffic cop at the entry gate.
Every instruction from a guest VM arrives here first.
It examines the instruction type and routes it to the correct module.
Example: A guest tries to run ADD EAX, EBX (arithmetic) → not sensitive → route to execute directly. A guest tries to run OUT (I/O operation) → sensitive → route to Interpreter.

② ALLOCATOR:

Manages which physical resources (CPU time, memory pages, disk I/O bandwidth) each VM gets.
Invoked when a VM instruction would change the machine resources assigned to that VM.
Example: VM-1 requests 4 GB RAM. The Allocator checks if 4 GB is available and grants/denies accordingly. It also enforces limits so VM-1 cannot take RAM away from VM-2.

③ INTERPRETER:

Contains routines (small programs) that safely simulate privileged instructions.
When a guest executes a privileged instruction, hardware causes a trap (interrupt). The Interpreter catches this trap and executes a software simulation of what the instruction would have done.
Example: Guest OS runs HLT (halt CPU). In real hardware, this stops the processor. The Interpreter catches this and instead just pauses that VM's execution, while other VMs continue running normally.

3.6 Popek and Goldberg Theorems (1974)

Gerald Popek and Robert Goldberg defined the formal mathematical conditions a CPU must meet for a correct and efficient VMM to be built. These are the foundational theorems of virtualization theory.

Three Required Properties of a VMM:

Equivalence: A program running in a VM must behave identically to running on real hardware.
Resource Control: The VMM must be in complete control of all virtualized resources.
Efficiency: Most instructions must execute directly on hardware (not intercepted by VMM) for performance.

Theorem 1: "When Can a VMM Be Built?"

"A VMM may be constructed if the set of sensitive instructions is a SUBSET of the set of privileged instructions."

What this means:

All sensitive instructions must cause a trap when run in user mode.
If a sensitive instruction does NOT cause a trap (like the x86 "17 problem"), the VMM cannot intercept it, and it cannot guarantee control.

IDEAL CASE (Theorem 1 satisfied):
  +---------------------------+
  |   All Instructions        |
  |  +---------------------+  |
  |  |   Privileged        |  |
  |  |  +---------------+  |  |
  |  |  |  Sensitive    |  |  |  <-- Sensitive ⊆ Privileged = VMM CAN be built
  |  |  +---------------+  |  |
  |  +---------------------+  |
  +---------------------------+

BROKEN CASE (x86 before VT-x):
  +---------------------------+
  |   All Instructions        |
  |  +----------+  +-------+  |
  |  |Privileged|  |Sensitv|  |  <-- Some sensitive instructions OUTSIDE privileged
  |  +----------+  +-------+  |      These don't trap! VMM loses control.
  +---------------------------+

Theorem 2: "Recursive Virtualization"

"A machine is recursively virtualizable if it is virtualizable AND a VMM without timing dependencies can be built for it."

What this means:

You can run a hypervisor inside a hypervisor (VM inside a VM).
This is used in cloud environments for nested virtualization.
Example: Running VirtualBox inside a VMware VM.

  Physical Hardware
       |
  [Hypervisor L1 - e.g., KVM]
       |
  [VM running Hypervisor L2 - e.g., VirtualBox]
       |
  [VM inside VM - nested guest OS]

Theorem 3: "Hybrid VMM"

"A Hybrid VMM can be built if user-sensitive instructions are a subset of privileged instructions."

What this means:

A Hybrid Virtual Machine (HVM) is less efficient than a pure VMM.
In HVM, more instructions are interpreted (simulated in software) rather than executed natively.
All instructions in virtual supervisor mode are interpreted.
Trade-off: More overhead, but works on hardware that doesn't fully satisfy Theorem 1.

VMM Type	Efficiency	Requirement
Full VMM (Theorem 1)	High — most instructions run natively	All sensitive ⊆ privileged
Hybrid VMM (Theorem 3)	Lower — more instructions interpreted	User-sensitive ⊆ privileged

3.7 Hardware Virtualization Techniques (Detailed)

3.7.1 Full Virtualization

Definition: The guest OS runs completely unmodified, exactly as if it were on real hardware. The VMM provides a complete hardware emulation.

  Guest OS (unmodified Windows/Linux)
       |  (thinks it's on real hardware)
       v
  +-------------------------------------------+
  |  VMM: provides COMPLETE hardware illusion  |
  |  - Virtual CPU                            |
  |  - Virtual RAM                            |
  |  - Virtual NIC, Virtual Disk             |
  +-------------------------------------------+
       |
       v
  Real Physical Hardware

Advantage: No changes needed to the guest OS. Works with any OS.
Challenge: Intercepting privileged instructions is costly. Before Intel VT-x, VMware used binary translation to handle the 17 problematic x86 instructions.
Examples: VMware Virtual Platform (1999), VirtualBox (full virt mode), QEMU.

3.7.2 Paravirtualization

Definition: The guest OS is modified to be aware that it is running in a VM. Instead of issuing real hardware instructions, it makes hypercalls to the VMM — like API calls, but to the hypervisor.

  Modified Guest OS
       |
       |  hypercall: "please do this I/O operation for me"
       v
  +-------------------------------------------+
  |  VMM (thin — no need to trap/simulate)    |
  +-------------------------------------------+
       |
       v
  Real Physical Hardware

Advantage: Much better performance. No expensive trap-and-simulate needed for common operations.
Disadvantage: Requires source code of the guest OS (which is why it works great with Linux, but historically not with Windows).
Examples: Xen hypervisor (guest kernel is a modified Linux), VMware PVSCSI drivers.

Feature	Full Virtualization	Paravirtualization
Guest OS modification	None	Required (hypercalls)
Performance	Moderate	High
Isolation	Complete	Complete
Works with proprietary OS	Yes (Windows, etc.)	No (needs source code)
Examples	VMware ESXi, VirtualBox	Xen with PV Linux

3.7.3 Hardware-Assisted Virtualization

Definition: The CPU itself has special instructions and modes to natively support virtualization, removing the need for binary translation or OS modification.

Intel VT-x (Vanderpool Technology):

Adds two new CPU operating modes: VMX Root (hypervisor) and VMX Non-Root (guest OS).
When a guest performs a privileged operation, the CPU automatically causes a VM Exit (control goes to VMM). When the VMM is done, it does a VM Entry (returns to guest).
Eliminates the "17 sensitive instructions" problem entirely.

  +-------------------+
  | VMX Non-Root Mode |  <-- Guest OS runs here (thinks it's in Ring 0, but isn't)
  +-------------------+
        |  VM Exit (privileged instruction)
        v
  +-------------------+
  |  VMX Root Mode    |  <-- Hypervisor runs here (real Ring 0)
  +-------------------+
        |  VM Entry (return to guest)
        v
  +-------------------+
  | VMX Non-Root Mode |  <-- Guest resumes
  +-------------------+

AMD-V (Pacifica): AMD's equivalent technology.
Products using it (post-2006): KVM, VirtualBox, Xen HVM mode, VMware, Hyper-V.

3.7.4 Partial Virtualization

Definition: Only some aspects of the hardware are virtualized — not a complete machine. You cannot run a full guest OS, but many applications can run.

Primary Example: Address Space Virtualization (used in time-sharing systems).
Multiple processes each get their own virtual memory address space, but they share the same CPU, disk, and network.
This is actually what every modern OS does for user processes.
Historical milestone: Implemented on IBM M44/44X — a stepping stone toward full virtualization.

3.8 Operating System Level Virtualization

Definition: The OS kernel creates multiple isolated user-space instances (containers). There is no hypervisor. The kernel is shared, but each container thinks it has its own file system, network, and processes.

  +--------+  +--------+  +--------+
  |  Cont1 |  |  Cont2 |  |  Cont3 |   <-- Isolated containers
  +--------+  +--------+  +--------+
  +--------------------------------------+
  |         SHARED OS KERNEL            |   <-- One kernel, no hypervisor
  +--------------------------------------+
  |         Physical Hardware           |
  +--------------------------------------+

Origin — Unix chroot():

chroot("/newroot") changes the file system root for a process. It cannot see anything outside /newroot.
OS-level virtualization is a sophisticated evolution of this idea.

Comparison with Hardware Virtualization:

Feature	OS-Level Virtualization	Hardware Virtualization
Overhead	Near zero	Moderate
Kernel	Shared	Each VM has its own
Can run different OS?	No (all containers use host OS)	Yes (any guest OS)
Isolation level	Good (but shared kernel)	Strong (completely separate)
Examples	Docker, LXC, FreeBSD Jails	VMware, KVM, Xen

Examples: FreeBSD Jails, Solaris Zones, Linux LXC/Docker, Parallels Virtuozzo, OpenVZ.

3.9 Programming Language Level Virtualization

Definition: A compiler targets a virtual machine's instruction set (bytecode) instead of real CPU instructions. A runtime VM then interprets or JIT-compiles this bytecode on any real hardware.

  Java Source Code (.java)
         |
         | javac (compiler)
         v
  Java Bytecode (.class)   <-- platform-independent
         |
         +--------> JVM on Windows  --> runs
         +--------> JVM on Linux    --> runs
         +--------> JVM on macOS    --> runs

Stack-Based VM (Java JVM, .NET CLR):

Operations are done using an execution stack — push operands, execute operation, pop result.
Easy to interpret on any architecture.

Register-Based VM (Parrot, Dalvik/Android):

Operations use registers, closer to real hardware.
Slightly faster but harder to port.

JIT Compilation: Instead of interpreting bytecode line-by-line (slow), a Just-In-Time compiler translates frequently-used bytecode blocks into native machine code at runtime — best of both worlds.

Interpretation:     slow startup, slow execution (re-interprets each time)
Static Compilation: fast execution, but not portable (tied to one CPU)
JIT Compilation:    slightly slow startup, FAST execution + PORTABLE  ← Best

Timeline:

1966: BCPL language uses bytecode (first use of this idea)
1995: Sun Java / JVM — made this mainstream
2002: Microsoft .NET / CLR — major enterprise adoption

3.10 Application-Level Virtualization

Definition: A thin software layer allows applications built for one OS/architecture to run on a different OS/architecture — without installing the original OS.

Two Implementation Strategies:

① Interpretation:

Source Instruction  -->  [INTERPRETER]  -->  Execute Native Instructions
                                              (one-by-one, slow)

Minimal startup cost.
Huge runtime overhead — every single instruction is translated on-the-fly.

② Binary Translation:

Source Code Block   -->  [TRANSLATOR]  -->  Native Code Block (cached)
                                              (reused on subsequent calls, fast)

Large initial overhead (translation takes time).
Much faster after warmup — translated blocks are cached and reused.

Technique	Startup Cost	Runtime Speed	Caching?
Interpretation	Low	Slow	No
Binary Translation	High	Fast (after warmup)	Yes

Real-World Examples:

Wine: Runs Windows apps on Linux by reimplementing the Win32 API.
CrossOver: Runs Windows apps on macOS.
QEMU: Emulates ARM CPU on an x86 machine using binary translation.
VMware ThinApp: Packages a Windows app with its dependencies into a single portable executable.

3.11 Virtualization and Cloud Computing (The Connection)

  CLOUD SERVICE MODEL       VIRTUALIZATION TECHNIQUE USED
  +------------------+      +------------------------------+
  |  IaaS            | <--> |  Hardware-Level Virtualization|
  |  (e.g., AWS EC2) |      |  (VMware ESXi, Xen, KVM)     |
  +------------------+      +------------------------------+
  
  +------------------+      +------------------------------+
  |  PaaS            | <--> |  PL-Level Virtualization     |
  |  (e.g., GAE)     |      |  (JVM, .NET CLR containers)  |
  +------------------+      +------------------------------+
  
  +------------------+      +------------------------------+
  |  SaaS            | <--> |  Application Virtualization  |
  |  (e.g., Gmail)   |      |  (runs in your browser)      |
  +------------------+      +------------------------------+

3.11.1 Server Consolidation and VM Migration

Server Consolidation: Moving multiple VMs onto fewer physical servers when overall load is low. Saves energy by powering off empty servers.

  BEFORE CONSOLIDATION:             AFTER CONSOLIDATION:
  +------+  +------+  +------+      +------+  +------+
  |Server|  |Server|  |Server|      |Server|  |Server|
  |  A   |  |  B   |  |  C   |      |  A   |  |  B   |
  |[VM1] |  |[VM2] |  |[VM3] |      |[VM1] |  |      | <-- Server C
  | 20%  |  | 15%  |  | 10%  |      |[VM2] |  |      |     powered OFF
  +------+  +------+  +------+      |[VM3] |  |      |     (saves energy)
   Wasted CPU across 3 servers       | 75%  |  |      |
                                    +------+  +------+

Live Migration: Moving a running VM from Server A to Server B with near-zero downtime.

Copy the VM's memory pages to Server B in the background.
Briefly pause the VM, copy remaining changed pages ("dirty pages").
Resume VM on Server B. Total pause time: milliseconds.

Used by: Xen, VMware vMotion, KVM.

3.12 Advantages and Disadvantages of Virtualization

Advantages

Advantage	Detail
Isolation	VMs are completely sandboxed. A crash or virus in VM-1 cannot affect VM-2.
Security	VMM can filter all guest operations, preventing harmful actions against the host.
Portability	VMs are files. Move them to any compatible hypervisor and they just work.
Cost Savings	Fewer physical servers needed → lower hardware, energy, and admin costs.
Efficient Resource Use	Run multiple workloads on one machine at high CPU utilization (80%+).
Live Migration	Move VMs without downtime — enables zero-disruption maintenance.
Snapshot/Rollback	Save VM state at any point. Revert to it instantly if something goes wrong.

Disadvantages

Disadvantage	Detail
Performance Overhead	VMM adds latency. Each privileged instruction must be trapped and simulated.
Feature Loss	Some host hardware features (special GPU modes, hardware security chips) cannot be exposed through the VM.
Security Holes: VM Escape	A bug in the VMM can let a guest break out and attack the host.
Malware: BluePill	Malware that slides itself under the OS as a rogue hypervisor, making detection impossible from within the guest.
Malware: SubVirt	Microsoft/Michigan prototype malware that installs a VMM under the OS and gains complete control on reboot.

Note on BluePill and SubVirt:

  Normal System:
  [OS] --> [Physical Hardware]

  After BluePill/SubVirt Infection:
  [OS] --> [ROGUE VMM (malware)] --> [Physical Hardware]
            ^^^^^^^^^^^^^^^^^^^^
            OS thinks it's on hardware, but malware has full control
            Can intercept passwords, encrypt data, exfiltrate anything

3.13 Comparison Summary Table

Technique	Guest Modified?	Needs Special HW?	Performance	Guest OS Independent?	Example
Full Virtualization	No	No (or Yes w/ VT-x)	Moderate	Yes	VMware, VirtualBox
Paravirtualization	Yes (hypercalls)	No	High	No (needs source)	Xen PV
Hardware-Assisted	No	Yes (Intel VT/AMD-V)	Highest	Yes	KVM, Hyper-V
Partial Virtualization	N/A	No	Very High	Partial	Time-sharing OSes
OS-Level (Containers)	No	No	Near-native	No (shares kernel)	Docker, LXC
PL-Level (JVM)	N/A	No	Good (JIT)	Yes	Java, .NET
Application Level	N/A	No	Moderate	Partial	Wine, ThinApp

Navigation

← Previous Next →