Virtualization | Computer Science

flowchart TD
    A[8_Virtualization] --> B[Key Concepts]
    A --> C[Core Principles]
    A --> D[Practical Applications]
    B --> E[Fundamental definitions]
    C --> F[Design patterns]
    D --> G[Real-world usage]

• Discrete Mathematics
• Algorithm Implementation

Virtualization lets one physical machine act as many by sharing hardware resources across multiple isolated environments. The key insight is that most hardware is idle most of the time — virtualization exploits this by letting multiple operating systems share the same CPU, memory, and I/O devices.

Type 1 vs Type 2 intuition: A Type 1 hypervisor runs directly on hardware (like a mini-OS managing VMs). A Type 2 hypervisor runs as an application on top of a host OS. Type 1 is faster (no OS layer in between) but less flexible. Type 2 is easier to install and manage but adds a full OS of overhead.

Container vs VM intuition: VMs emulate entire hardware stacks — each VM runs its own OS kernel. Containers share the host OS kernel but isolate processes, files, and networking. Containers are lighter (start in milliseconds, use less memory) but offer weaker isolation (shared kernel = larger attack surface). Use VMs for strong isolation; use containers for lightweight deployment.

Type 1 (bare-metal). Runs directly on hardware. Examples: VMware ESXi, Xen, Hyper-V.

• Direct hardware access; high performance.
• Must include device drivers for all hardware.

Type 2 (hosted). Runs on a host OS. Examples: VirtualBox, VMware Workstation, QEMU.

• Easier to develop and install.
• Additional overhead from the host OS.

A VMM (hypervisor) presents the illusion of multiple independent physical machines to guest OSes.

Challenges:

• Instruction emulation: Sensitive instructions must be trapped and emulated. On x86, IN OUT``HLT``CLI``STIAnd MOV to/from control registers are sensitive.
• Memory virtualization: The VMM maintains shadow page tables mapping guest virtual to host physical addresses. Hardware support: Extended Page Tables (EPT, Intel) and Nested Page Tables (NPT, AMD).
• I/O virtualization: Device access mediated by the VMM. Paravirtualized drivers (e.g., VirtIO) improve performance.

The guest OS is modified to make hypercalls instead of executing sensitive instructions directly.

• Advantage: Lower overhead (no trap-and-emulate for every sensitive instruction).
• Disadvantage: Requires modifying the guest kernel.

Containers share the host kernel but provide process isolation via:

• Namespaces: Isolate process trees, network, file systems, IPC, UTS (hostname).
• cgroups: Limit resource usage (CPU, memory, I/O).

Docker uses OverlayFS for layered images. Kubernetes orchestrates containers across clusters.

• Assuming containers provide the same isolation as VMs. Containers share the host kernel; a kernel exploit can compromise all containers. VMs provide hardware-level isolation via separate kernel instances.
• Confusing paravirtualization with full virtualization. Paravirtualization requires a modified guest OS; full virtualization does not (hardware-assisted or binary translation).
• Forgetting that CPU virtualization includes more than just instructions. Timer interrupts, APIC virtualisation, and VMCS (VMX controls) must all be handled correctly for performance.
• Thinking nested virtualization is always supported. Running a hypervisor inside a VM requires nested VT-x/AMD-V support, which adds significant complexity and performance overhead.

Problem 1. A Type 1 hypervisor hosts 10 VMs, each with 4 GB RAM and 2 vCPUs. The host has 64 GB RAM and 16 physical cores. Estimate the memory overhead.

Solution. Each VM reserves 4 GB (total 40 GB). The hypervisor itself uses ~1 GB. Additional overhead: shadow page tables (~200 MB per VM), device emulation state (~100 MB per VM). Total overhead: $40 + 1 + 10 \times 0.3 = 44$ GB. Remaining for host cache and I/O: 20 GB. With EPT hardware support, the shadow page table overhead is eliminated. $\blacksquare$

Problem 2. Design a container strategy for a microservice with 12 services. Each service needs 50 MB RAM and starts in < 1 second. Compare with VM approach.

Solution. Containers: shared kernel, total RAM $\sim 12 \times 50 + 500$ MB (OS overhead) $\approx 1.1$ GB. Startup: seconds. VMs: each VM needs separate OS ($\sim 512$ MB minimum), total RAM $\sim 12 \times 512 = 6.1$ GB. Startup: minutes. Containers are superior for this lightweight microservice architecture. $\blacksquare$

• Cloud computing: AWS Nitro uses custom hardware (Nitro cards) to offload virtualisation overhead, achieving bare-metal performance for VMs. Google Cloud uses KVM-based virtualisation with and without nested containers via gVisor.
• Edge computing: Lightweight virtualisation (Firecracker by AWS) runs micro-VMs for serverless functions (Lambda, Fargate), combining VM isolation with container-like startup times.
• DevOps pipelines: CI/CD systems (GitHub Actions, GitLab CI) use container executors for reproducible build environments. Each job runs in an isolated container with pinned dependencies.
• Desktop virtualisation: VirtualBox and VMware Workstation enable running multiple OSes on a single desktop for software development, testing compatibility across platforms.

Problem. A host runs 20 web server instances. Each instance uses 256 MB RAM and 0.5 CPU cores at peak. Compare RAM usage for: (a) 20 VMs with 512 MB each, (b) 20 containers sharing host OS.

Solution. (a) VMs: each VM requires 512 MB (guest OS overhead) + 256 MB (application) = 768 MB per VM, total $20 \times 768 = 15.36$ GB RAM. (b) Containers: host OS uses 512 MB, each container adds 256 MB application + negligible OS overhead ($\sim 5$ MB per container), total $512 + 20 \times 261 \approx 5.73$ GB RAM. Containers use 63% less RAM in this scenario, enabling higher density on the same hardware. However, if instances run untrusted workloads, VMs provide stronger isolation. $\blacksquare$

This section provides detailed coverage of advanced concepts, including full derivations, proofs, and extended examples.

Complete mathematical derivations and proofs are provided where appropriate. Each step is explained to ensure understanding of the underlying reasoning.

Advanced examples demonstrate the application of concepts to complex problems. These examples go beyond standard exam questions to develop deeper understanding.

This material connects to current research and advanced applications in the field. Understanding these connections provides context for the study material.

Ensure you have mastered the prerequisite material before attempting this advanced content.