Virtualization Concepts

Picture one physical server in a rack quietly running a Windows file server, a Linux web server, and a throwaway test machine at the same time, each convinced it owns the box. That is virtualization: a virtual machine (VM) is a complete computer built in software, with its own virtual CPU, memory, disk, and network adapter, running its own guest operating system. The physical computer underneath is the host. This page stays on that local host you own and run yourself; renting the same capability from a provider as a metered, on-demand service is the sibling subject, covered in cloud computing models.

The hypervisor is the referee

The layer that makes this work is the hypervisor (also called the virtual machine monitor). NIST defines it as the virtualization component that manages the guest operating systems on a host and controls the flow of instructions between those guests and the physical hardware (NIST glossary^[1]). Two jobs matter for the exam: it shares the host's real CPU, RAM, storage, and network among the VMs, and it isolates them so a crash, a misconfiguration, or malware in one VM cannot reach the host or the other VMs.

Type 1 versus Type 2

Every hypervisor is one of two types, and they differ in exactly one thing: what sits directly beneath the hypervisor. The figure below stacks the two arrangements side by side so that one difference is visible at a glance.

• A Type 1 (bare-metal) hypervisor installs straight onto the hardware, with no general-purpose operating system underneath it. It effectively is the host's operating system. Microsoft describes Hyper-V this way: as a type-1 hypervisor it runs directly on the hardware (Hyper-V overview^[2]). VMware ESXi and Xen are the other common examples. With no extra OS layer to cross, Type 1 has lower overhead and a smaller attack surface, so servers and data centers run it.
• A Type 2 (hosted) hypervisor runs as an ordinary application on top of a desktop operating system you already booted, such as Windows or macOS. VMware Workstation, Oracle VirtualBox, and Parallels Desktop are Type 2. It is the easiest way to run a second OS on a laptop, at the cost of the extra host-OS layer between the VMs and the hardware.

One caution on names: Microsoft Hyper-V is a Type 1 hypervisor even when you enable it on a Windows 11 desktop, because Windows itself is moved on top of the hypervisor once the feature turns on. Do not assume that "runs on a desktop" means Type 2. Choosing between hypervisor types and setting up client-side virtualization is part of the A+ Core 1 virtualization objective^[3].

Before a single VM boots, the host has to be capable of virtualization and then large enough to share. The most common real-world failure is not size at all: the hypervisor refuses to start because the CPU's virtualization feature is switched off in firmware. The figure below walks the whole sequence in order, from confirming CPU support through allocating resources to starting the first VM.

The virtualization extensions must be enabled in UEFI/BIOS

Modern processors include hardware virtualization extensions, called Intel VT-x (Virtualization Technology) or AMD-V (AMD Virtualization), that let a hypervisor run guest code safely and quickly. These often ship disabled, so enabling them in the UEFI/BIOS firmware setup is step one. Microsoft's client Hyper-V requirements spell out the same switch: virtualization support turned on in the BIOS or UEFI, meaning hardware-assisted virtualization (Intel VT or AMD-V) plus hardware-enforced DEP (Data Execution Prevention), which is the Intel XD bit or the AMD NX bit (Hyper-V system requirements^[4]).

SLAT and a 64-bit CPU

Hyper-V also needs a 64-bit processor with SLAT (second-level address translation), a CPU feature that lets the hardware, rather than the hypervisor, translate a guest's memory addresses, which cuts overhead. The published floor is a 64-bit CPU with SLAT, VM Monitor Mode extensions, and at least 4 GB of RAM (Hyper-V system requirements^[4]). On Windows you can confirm all of this by running systeminfo and reading its Hyper-V Requirements section.

Size the host for itself plus every VM

Each running VM reserves a real slice of the host, so the host must cover its own needs plus the sum of what its VMs use at the same time:

• CPU: cores and threads are shared out to VMs; oversubscribing many busy VMs onto too few cores makes all of them slow.
• Memory (RAM): usually the first ceiling you hit. A VM's assigned RAM is largely carved out of the host, so four 4 GB VMs want roughly 16 GB before the host's own overhead.
• Storage: each VM's virtual disk is a file or volume on the host that consumes real capacity and disk I/O.
• Network: VMs reach the network through a virtual switch the hypervisor presents, mapped onto the host's physical network adapter.

Undersize any one of these and VMs either refuse to start or contend with each other. Sizing a machine's memory, CPU, and storage is covered as hardware in RAM, CPUs, and storage; here the point is that a VM's needs stack on top of the host's.

You have one laptop and need to try a suspicious installer, run an app that only works on an older Windows, and keep a clean Linux for a class, all without risking your real desktop. That is the everyday case for client-side virtualization: a Type 2 hypervisor or a built-in sandbox on your own machine, rather than a server in a data center.

Desktop hypervisors and sandboxes

A desktop Type 2 hypervisor (VMware Workstation, VirtualBox, Parallels) lets you create full VMs on a PC. A sandbox goes lighter: it is a disposable, isolated environment for running one risky thing safely. Windows Sandbox is the built-in example, a lightweight isolated desktop that keeps whatever you install isolated from the host using hypervisor-based virtualization, and it is disposable, so closing it deletes all software, files, and state, and every launch is a fresh, clean instance (Windows Sandbox overview^[5]). It needs Windows Pro, Enterprise, or Education (not Home) and virtualization enabled in firmware, the same switch from the previous section. The figure below traces that disposable lifecycle: a fresh, clean instance at launch, the risky app or file running isolated from the host, and all state discarded when you close it. That is the client-side choice in one line: a desktop hypervisor when you need a full VM to work in, a sandbox when you need one risky thing to run and then be discarded.

Knowing how a hypervisor works only pays off if you can say why anyone would run a VM in the first place. Virtualization shows up on the exam as "why would you use a VM here," and the answers cluster into a short list:

• Cross-platform and legacy software: run the operating system an app requires (an old Windows release, or Linux on a Windows host) without dedicating hardware to it.
• Test and development: build, break, and rebuild environments that mirror production, then roll back a snapshot or discard the VM.
• Sandboxing: open an untrusted file or run unknown software in isolation so it cannot touch the host.
• Training and labs: hand every learner an identical VM image they can reset to a known-good state.
• Resource efficiency (consolidation): pack many VMs onto one capable host to cut hardware, power, and cooling, the core reason data centers virtualize.

The thread through all of them is isolation

Notice the common mechanism: each VM is a walled-off computer. That isolation is what lets a test crash, a piece of malware, or a bad patch stay contained to its VM while the host and its neighbors keep running.

Two considerations decide whether a virtualized setup is healthy: how resources are shared, and how isolation holds. Both are frequent exam targets, and both come down to the hypervisor doing its two jobs well.

Resource allocation: do not starve the host

A hypervisor can oversubscribe, promising VMs more virtual CPU or memory than the host physically has, on the bet that not all VMs peak at once. That works until they do, and the fix is to leave headroom for the host itself and to keep total VM demand under the host's real capacity. The classic mistake is allocating so much RAM to VMs that the host has none left, which drags every VM down together.

Security considerations: isolation, and where it breaks

Isolation is the security benefit and also the thing attacks target. The worst-case virtualization flaw is a VM escape, where code inside a guest breaks out of its VM to reach the hypervisor or the other guests, defeating the isolation the whole model depends on (NIST glossary^[1]). Patching the hypervisor, limiting what a VM can touch, and keeping snapshots for rollback are the routine defenses. One more point candidates miss: a VM is only as isolated as its network lets it be, so a VM on the same virtual switch as production is not automatically walled off from it.

How the questions read

Question stem says	Right answer	Common wrong answer
Hypervisor installs directly on hardware, no host OS	Type 1 (bare-metal)	Type 2, which needs a host OS first
Run a VM on your Windows laptop to try software	Type 2 (hosted) hypervisor	Type 1, which would replace the desktop OS
Hypervisor will not start, virtualization unavailable	Enable VT-x or AMD-V in UEFI/BIOS	Buying a faster CPU when the setting is just off
Open one risky file, discard everything after	Sandbox (disposable)	A full persistent VM you must clean up by hand
Consolidate many servers onto one box	Virtualize with a Type 1 hypervisor	Adding more physical servers
Guest code reaches the hypervisor or other VMs	VM escape	A normal, permitted cross-VM feature

Each row rewards matching the scenario to virtualization's two jobs, sharing and isolating, and rejecting the option that ignores a stated constraint (no host OS, must be disposable, the setting is just off). Recognizing virtualization purposes and requirements is the A+ Core 1 virtualization objective^[3].