openskills.info
Course catalog
Open Course

Virtualization Fundamentals

Virtualization lets one physical computer host multiple software-defined computers called virtual machines. A hypervisor divides processor time, memory, storage, and network access while each virtual machine runs its own operating system.

itVirtualization, containers, and orchestration

Don't Panic — Virtualization Fundamentals

Virtualization is a disciplined deception: one physical computer agrees to behave like several. Each virtual machine is a software-defined computer with processors, memory, disks, network interfaces, firmware, and its own operating-system kernel. The guest believes the arrangement because the arrangement is, from its point of view, hardware.

The physical computer is the host. Between host and guest sits the hypervisor, which schedules CPU time, maps memory, connects virtual devices, and enforces the boundary between VMs. It is less a conjurer than an extremely strict landlord. Every guest gets an address, a set of keys, and no claim on the entire building.

Without that boundary, an operating system controls the physical machine directly. Virtualization detaches the operating environment from one server, so workloads with different kernels and dependencies can share capacity or move between compatible hosts. The hardware has not vanished. It has acquired a booking system.

The first surprise is the vCPU. It is not a tiny physical core reserved under a glass dome. It is work the hypervisor schedules onto physical CPU capacity. Overcommit is useful while workload peaks take turns; when they arrive together, steal time or scheduling wait reveals the queue. Adding more vCPUs to a crowded host merely gives the queue more paperwork.

Memory performs a similar two-step. The guest maps application addresses to what it thinks is physical memory, then the hypervisor maps that memory onto the host. Storage and networking also cross virtual devices before reaching physical resources. This layering buys mobility and control, while ensuring that performance investigations have at least two perfectly sincere versions of events.

A snapshot records point-in-time VM state. It is excellent for a short rollback window and remarkably unqualified for promotion to backup. It may depend on the base disk and the same storage system, and consolidation can suspend I/O while changed blocks are merged. An independent, tested restore remains stubbornly independent and tested.

Separate VMs are not automatically separate failures. Two application replicas can occupy one host, and shared storage can give many hosts one common problem. Placement rules, failure-state capacity, and actual restore tests turn architectural diagrams into recovery behavior. The management plane matters too: guests may keep running while the ability to move or reconfigure them disappears.

Containers are relatives, not aliases. A VM carries a guest kernel and virtual hardware boundary. A container normally shares the host kernel and isolates processes. Many systems put containers inside VMs, because infrastructure has never allowed one useful boundary to prevent it from adding another.

Read the Intro for the complete architecture and resource paths. Keep the Cheatsheet nearby when choosing CPU, memory, storage, networking, and recovery mechanisms. Field Notes covers the operational traps that polite diagrams omit. The Exercise boots a real VM under software emulation and lets the guest and hypervisor disagree in public, which is where the mental model becomes useful.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources