Virtualization: hypervisors, machine types and what the cloud is built on

Why this matters

Every public cloud is a virtualization platform with a billing system and an API in front of it. Almost everything else in this course sits on top of what this lesson describes, and a candidate who is vague about hypervisors ends up vague about performance, about isolation, and about why containers are different.

It also carries a practical payoff. The distinction between an image, a snapshot, a template and a clone decides what you can actually recover after a bad change — and that is a question people get wrong in production, not just in exams.

The lesson

Type 1 and type 2 hypervisors, and which one every cloud provider runs

A hypervisor presents virtual hardware to guest operating systems and schedules real hardware underneath.

• Type 1, "bare metal". Runs directly on the hardware; there is no general-purpose operating system beneath it. Lower overhead, stronger isolation, and what every cloud provider runs. Examples in the wild: ESXi, Hyper-V in its server role, KVM as used by providers, Xen.
• Type 2, "hosted". Runs as an application on a conventional operating system. Convenient on a workstation, higher overhead, and the right choice for your own lab. Examples: VirtualBox, VMware Workstation Player.

The exam cue is the phrase "installed on the host operating system" for type 2 and "installed directly on the hardware" for type 1. The practical cue is whether you can be doing something else on the machine at the same time.

Two related ideas belong here:

• Hardware-assisted virtualization (Intel VT-x, AMD-V) is what makes modern virtualization fast. If it is disabled in firmware, guests either refuse to start or run very slowly — a genuine troubleshooting scenario.
• Paravirtualization means the guest knows it is virtualized and uses optimised drivers instead of emulated hardware. In practice this is why you install the provider's or hypervisor's guest tools: emulated devices work, paravirtual ones are much faster.

Virtual machine anatomy: vCPU, virtual memory, virtual disks and virtual NICs

A virtual machine is a set of virtual devices plus a configuration describing them.

• vCPU. A schedulable thread on a physical core, not a dedicated core. The hypervisor timeshares physical cores among vCPUs, which is the root of the contention behaviour in the next lesson.
• Memory. Allocated to the guest, with the hypervisor able to reclaim it under pressure through techniques the guest does not see.
• Virtual disks. Files or volumes presented as block devices. Two provisioning styles matter: thick (space allocated up front, predictable performance) and thin (allocated as written, efficient but capable of over-committing real capacity — and a thin-provisioned datastore that fills up stops every guest on it at once).
• Virtual NICs. Attached to a virtual switch or a provider virtual network. In a cloud the NIC is usually a first-class object with its own identity, addresses and security rules, which matters when you detach and reattach one.

Templates, images, snapshots and clones, and the difference that matters at restore time

These four words are used loosely in conversation and precisely in exams.

• Image. A reusable, usually read-only starting point for new instances — operating system plus baseline configuration. In a cloud this is what you select at launch.
• Template. An image plus the configuration metadata to deploy from it: sizing, network attachment, bootstrapping. The distinction from "image" is softer, and providers use the words differently, so read what the scenario describes rather than the word it uses.
• Snapshot. A point-in-time capture of a specific instance's disks. Fast to take, fast to roll back, and tied to the thing it came from.
• Clone. A full, independent copy of an existing instance, which then diverges.

The distinction that costs people real data is this: a snapshot is not a backup. It usually lives on or beside the same storage as the volume it protects, it is tied to that volume's lifecycle, and deleting the instance can delete it. It protects against a change — a bad patch, a bad configuration — and not against the loss of the underlying storage, the account, or the region. Objective 3.2 returns to this, and the exam tests it in both places.

A second distinction worth holding: reverting a snapshot reverts everything on that instance, including data written since. Taking a snapshot before a risky change is good practice; treating it as a way to recover one file later is not.

Instance families, and why a general-purpose size is the wrong default for a database

Providers group instance types into families optimised for different ratios of resources. The names differ; the categories are consistent:

• General purpose — balanced CPU-to-memory. A sensible default for web and application tiers.
• Compute optimised — more CPU per unit of memory. Batch processing, encoding, some application servers.
• Memory optimised — much more memory per vCPU. Databases, caches, in-memory analytics.
• Storage optimised — high local disk throughput and IOPS. Data warehouses, distributed file systems.
• Accelerated — GPUs or other accelerators. Training, inference, rendering.

The database case is the one to remember because it is the common mistake. A database's working set wants to live in memory; when it does not, the system falls back to disk and the symptom looks like a storage problem. Sizing a database on a general-purpose family means paying for CPU you will not use while starving the thing that actually determines performance. Objective 1.7 develops this into right-sizing as a discipline.

The related trap: instance size caps more than CPU and memory. Network bandwidth and storage throughput are usually tied to instance size too, so a "small" instance can hit a network ceiling long before it runs out of CPU. That is a recurring troubleshooting scenario in objective 6.2.

Nested virtualization and GPU passthrough, and the cases that need them

Two specialised capabilities appear in exam scenarios as the answer to a requirement that nothing else satisfies.

Nested virtualization runs a hypervisor inside a virtual machine. It needs explicit support from the platform and the instance type, it carries a performance penalty, and the legitimate uses are narrow:

• running a lab or training environment inside a cloud instance;
• a build or test pipeline that must create virtual machines;
• migrating an existing virtualization platform without re-architecting it.

GPU passthrough gives a guest direct access to a physical accelerator rather than an emulated device. It is required where the workload needs the hardware's real capability — machine learning, rendering, virtual desktops with graphics needs, some scientific computing. The trade is that a passed-through device is usually dedicated to that guest and cannot be shared, which reduces flexibility and makes live migration harder or impossible.

The exam cue for both is a requirement that cannot be met by ordinary virtualization: "the test suite must provision its own virtual machines" points to nested virtualization; "the model training job needs direct access to the accelerator" points to passthrough.

What to take into the exam

• Type 1 runs on the hardware; type 2 runs on an operating system. Every cloud provider runs type 1.
• A vCPU is a scheduled thread, not a dedicated core.
• Thin provisioning can over-commit real capacity; a full thin datastore stops every guest on it.
• A snapshot is not a backup. It is tied to the instance, it usually shares its storage, and reverting it reverts everything.
• Match the instance family to the resource that limits the workload — memory optimised for databases, not general purpose.
• Instance size also caps network and storage throughput, which is a common hidden ceiling.
• Nested virtualization for guests that must themselves virtualize; GPU passthrough where emulated hardware will not do.