Week 13: Virtualization and Containers Flashcards
Learn about many fundamental technologies that enable cloud computing, such as software defined architectures, virtualization, and containers. (25 cards)
What is virtualization, and what is its main idea?
Virtualization is the abstraction layer that lets one physical computer present itself as many “virtual” machines by emulating a generic computing resource model.
Its main idea is to share hardware among multiple users without creating dependencies on the underlying physical resources, enabling isolation and flexible resource management in cloud environments.
Describe the OS modes (user and kernel modes), including what they are, similarities, and differences.
User mode: Where regular applications run; cannot execute privileged (sensitive) instructions directly.
Kernel mode: Where the OS and device drivers run; can execute all instructions, including I/O and interrupt management.
Similarity: Both are CPU execution modes enforced by the processor to manage code execution.
Difference: Only kernel mode can perform privileged operations; transitions between modes occur on system calls, traps, or interrupts to enforce isolation.
What are CPU privilege levels, and why are they important?
CPU privilege levels (e.g., x86 rings 0–3) define hierarchical execution domains: ring 0 for kernel, ring 3 for user.
They prevent untrusted code from executing sensitive instructions (e.g., manipulating page tables or I/O devices).
Importance: Enforces security and isolation by causing a fault if a lower‑privilege code attempts a privileged operation.
Explain the different types of virtualization (full and paravirtualization). What are the similarities and differences?
Full virtualization: Hypervisor traps and emulates all sensitive instructions; runs an unmodified guest OS as if on real hardware.
Paravirtualization: Guest OS is modified to replace privileged operations with hypercalls to the hypervisor (no need to trap on every unsafe instruction).
Similarity: Both isolate multiple guests on one physical machine via a hypervisor.
Difference: Full virtualization needs no OS changes but incurs trap/exit overhead; paravirtualization requires OS modifications but reduces trap overhead and boosts performance.
What are the Xen concepts?
Dom0 (Control Domain): Privileged domain running the Xen management stack and device drivers.
DomU (Guest Domains): Unprivileged guests where user applications run.
Driver/Stub/Service Domains: Isolated, de‑privileged domains that host specific drivers or services (lifecycle: start/stop/kill).
What is the purpose of binary translations?
To dynamically rewrite “unsafe” or non‑virtualizable instructions in a guest kernel into safe equivalents at runtime, enabling full virtualization on hardware lacking native trap support.
Allows unmodified guest OSes to run by translating only the small fraction of kernel code that needs virtualization.
What are the core architectural features and challenges of first-generation hardware virtualization?
Features:
New guest execution mode (via Intel VT‑x/AMD‑V) with a virtual machine control block (VMCB) storing guest state.
vmrun/vmexit instructions switch between host and guest modes.
Challenges:
No hardware support for memory virtualization—hypervisor must maintain software shadow page tables.
Frequent VM exits for MMU operations add overhead.
Why did first-generation virtualization underperform in memory management? What were the issues with shadow page tables and frequent exits?
The hypervisor had to:
Write‑protect guest page tables to trap on updates.
Exit on every page fault to distinguish “hidden” vs “true” faults and populate shadow tables.
Exit on context switches to switch in the correct shadow table.
These extra traps/exits and software‑maintained shadow tables caused high overhead and poor scaling.
How did second-generation hardware virtualization (e.g., EPT, RVI) improve upon the first generation?
Introduced nested page tables (EPT on Intel, RVI on AMD) where hardware walks a second-level table to translate guest‑physical to host‑physical addresses.
Eliminated the need for shadow page tables, trace‑induced exits, context‑switch exits, and hidden/true fault exits.
Reduced memory usage and hypervisor involvement at the cost of slightly higher TLB‑miss handling, mitigated by TLB caching and large pages.
What were the innovations in third-generation virtualization? How did they help?
VMCS shadowing: Accelerates nested virtualization by reducing VMCS (control block) exits.
Interrupt virtualization (AMD AVIC, Intel APICv): Offloads virtual interrupt handling to hardware.
I/O MMU virtualization (AMD‑Vi, Intel VT‑d) and SR‑IOV: Enables direct guest DMA and interrupt remapping for near‑native I/O performance and secure device passthrough.
What distinguishes MicroVMs and Firecracker from traditional VMs (ex: speed, device support, and memory efficiency)?
MicroVMs: Minimal device emulation (just virtio net, virtio block, keyboard, timer, interrupt controller); designed for serverless/container use.
Firecracker:
VMM boot in ≈ 8 ms; VM start < 125 ms.
Memory overhead < 5 MiB.
No graphics or extra virtual devices—maximizes density and startup speed.
How do Unikernels differ from a standard OS? What are the benefits and trade-offs?
Unikernels: Compile application code and only the needed OS components (syscalls, drivers) into a single-address-space VM image, running one process with no forking.
Benefits: Extremely small footprint, fast boot (e.g., < 5 ms on Firecracker), minimal memory overhead (≈ 18 MiB), and reduced attack surface.
Trade‑offs: Limited to one application per VM, complex build/debug process, and less flexibility compared to general-purpose OSes
What is Operating System-Level Virtualization?
Virtualizing a physical server at the OS level to run multiple isolated, secure “virtual” servers on one physical machine.
Processes share the same real kernel but each think they have a private kernel; the kernel enforces boundary isolation.
Examples: Solaris Containers (2004), FreeBSD Jails (2000), Linux Vserver (2001), OpenVZ (2005), Process Containers via cgroups (2006), LXC (2008), Docker (2013).
What are the similarities and differences between VMs and containers, and what are their respective use cases?
Similarity: Both isolate workloads on shared hardware and allow multiple environments.
VMs (Hypervisor): Emulate full hardware → run different OSes; lower density, higher overhead; best for mixed‑OS or legacy workloads.
Containers: Share host kernel → many user‑space instances; near‑native performance, high density; ideal for microservices and scalable cloud apps.
Describe OS virtualization and containers. Provide examples.
OS virtualization: “Lightweight” virtualization where processes think they each have a private kernel but all share the same underlying kernel.
Containers: Realization of OS virtualization.
Examples: Solaris Containers, FreeBSD Jails, Linux Containers (LXC), Docker, OpenVZ.
What are the 3 building blocks (pillars) of a container?
cgroups (Control Groups) – resource limiting/isolation
Namespaces – resource visibility isolation
Unionfs (Union File System) – layered filesystem + copy‑on‑write
What are control groups, and how are they implemented?
Control Groups (cgroups): Linux kernel feature to limit, isolate, and measure resource usage (CPU, memory, I/O, etc.) of a group of processes.
Implementation:
Kernel controllers (e.g., cpu, memory, io, pids) mounted under /sys/fs/cgroup/<controller>.</controller>
Set resource limits by writing to control files (e.g., memory.limit_in_bytes).
Assign processes via cgexec or writing PIDs to cgroup.procs.
CPU scheduling uses CFS with cpu.shares.
What types of Linux namespaces are used to isolate container resources, and how do they work together?
Namespaces wrap global resources, giving each container its own instance:
Cgroup (cgroup root)
IPC (System V IPC, POSIX queues)
Network (devices, IPs, routes, ports)
Mount (filesystem views)
PID (process ID hierarchies)
Time (clocks)
User (UID/GID mappings)
UTS (hostname/domain)
Combined, these namespaces isolate resource trees, IPC, network stacks, filesystems, process trees, clocks, user IDs, and hostnames.
How do PID and network namespaces provide process and networking isolation?
PID Namespace:
Gives each container a separate PID hierarchy; the first process inside is PID 1.
Processes inside cannot see or signal processes outside; each process has both a namespace‑local PID and a global PID.
Network Namespace:
Provides each container its own networking stack (interfaces, IP addresses, routing tables, /proc/net, ports).
Isolates packet flows and port spaces so containers cannot interfere with each other’s network.
How does the union filesystem enable container layering, copy-on-write behavior, and efficient storage management?
Unionfs: Merges multiple directory branches into a single unified mount without altering physical data.
Layering: Container images are stacks of immutable layers; a top read‑write layer is added at runtime.
Copy‑on‑Write: Modifying a file in a lower, read‑only layer triggers copying it to the top read‑write layer, preserving base layers and saving space.
What are graph drivers, and how do different storage backends affect container performance and functionality?
Graph Drivers: Manage Docker image layer caching and retrieval.
Backends:
vfs: Simple, no CoW or union.
aufs/overlay/overlay2: Implement unionfs on ext4, xfs, etc.
btrfs/zfs/devicemapper: Leverage native filesystem CoW.
Impact: Choice influences metadata overhead, snapshot speed, storage efficiency, and feature support (e.g., quotas).
What is the architecture of the Docker engine, and how do the components interact with each other?
Docker CLI: User-facing tool that sends commands to the Docker daemon’s REST API.
Docker Daemon (Engine): Exposes REST endpoint; coordinates container lifecycle.
containerd: Handles image push/pull, storage, networking, and invokes runc.
runc: Low-level, OCI‑compliant runtime that spawns containers with namespaces and cgroups.
How does Docker support container lifecycle management through modular container runtimes and REST-based orchestration?
Modular Runtimes:
containerd: High-level functions (image management, networking).
runc: Actual process spawning and runtime.
REST API: Docker daemon exports container operations (create, start, stop, rm) via REST; used by CLI and orchestrators (e.g., Swarm)
What are the core components of the Docker Container Network Model (CNM)?
Sandbox: Abstraction of a container’s network stack (interfaces, routes, DNS) — implemented as a network namespace.
Endpoint: Connection point between a sandbox and a network (e.g., veth pair).
Network: Collection of endpoints that can communicate (bridge, overlay, VLAN).
Drivers: Plugins implementing network primitives (CreateNetwork, CreateEndpoint, Join, etc.).
