Virtualization

Everything in this course so far has described one kernel, running directly on hardware, mediating access for every process above it. Virtualization changes that picture: it lets Windows itself become one of potentially several operating system instances sharing the same physical machine, coordinated by a layer beneath all of them.

The hypervisor sits below the kernel, not beside it

A hypervisor is software that runs at a privilege level below the OS kernel — genuinely below the ring 0/kernel-mode boundary introduced in System architecture, not merely "another privileged program." It uses hardware virtualization extensions (Intel VT-x, AMD-V) to trap sensitive operations that a guest operating system's kernel attempts, allowing the hypervisor to multiplex real hardware — CPUs, memory, devices — across multiple isolated partitions, each running what believes itself to be a normal, unshared operating system.

Windows' own hypervisor, Hyper-V, uses a root partition (running the management operating system — ordinarily the Windows install you're actually using day to day) and one or more child partitions (running guest operating systems). Hyper-V & partitions covers this structure in detail.

Not just for running "a VM" you deliberately created

A common misconception this level exists partly to correct: virtualization on a modern Windows machine isn't only relevant if you've deliberately opened Hyper-V Manager and created a virtual machine. WSL2 runs its Linux environment as a genuine lightweight virtual machine on top of the same Hyper-V infrastructure, integrated tightly enough with the Windows desktop experience that most users never consciously think of it as "a VM" at all. And virtualization-based security — covered in this level's second chapter — uses the exact same hypervisor infrastructure for a completely different purpose: hardening the host kernel itself, not running guest operating systems at all.

Virtual machines are not containers

Worth stating precisely, since the two get conflated constantly in casual conversation: a virtual machine runs its own separate, complete kernel, isolated from the host by the hypervisor boundary described above. A container, by contrast, shares the host's single kernel, achieving isolation through kernel-level mechanisms (namespaces, resource limits) rather than through a hardware-enforced hypervisor boundary. This is a genuinely different isolation model with different security properties: a kernel vulnerability generally can't cross a well-implemented VM boundary at all (it would have to escape the hypervisor itself, a much harder and rarer class of exploit), while a kernel vulnerability can, in principle, be exploited from inside any container sharing that same kernel.

A worked example: why enabling Hyper-V doesn't "put your desktop in a VM"

Turning on the Hyper-V feature doesn't retroactively virtualize the Windows install you're already running — the machine's original Windows instance becomes the root partition, still running essentially natively with direct hardware access, now additionally capable of hosting child partitions alongside itself. This is a specific, common point of confusion worth being precise about: your desktop experience after enabling Hyper-V is running as the management OS in the root partition, not as a guest inside some new virtual layer.

Where this connects

• Hyper-V & partitions covers the actual mechanics: virtual CPUs, memory backing, and synthetic devices.
• VBS, HVCI & isolation covers how the same hypervisor infrastructure gets repurposed for hardening the host kernel itself.