Hyper-V & partitions

Virtualization introduced the root/child partition model at a high level. This chapter goes into the mechanics: how virtual CPUs actually get scheduled, how guest memory is backed, and why "integration services" matter as much as they do for a virtual machine's real-world performance.

Virtual CPUs: scheduled, not dedicated

A guest partition doesn't get a physical CPU core reserved exclusively for it. Instead, the hypervisor creates virtual processors (vCPUs) for each partition and schedules them across the machine's actual logical CPUs — conceptually similar to how the OS-level scheduler covered in Scheduling multiplexes threads across physical cores, but one level further down, multiplexing entire virtual CPU contexts (belonging to potentially several different guest operating systems) instead of individual threads within one OS.

Guest memory: backed by host RAM, translated through nested page tables

A guest OS manages its own virtual-to-physical memory translation exactly as it would on real hardware — from the guest kernel's point of view, nothing about its own paging and page fault machinery is aware it's running virtualized at all. The hypervisor adds an additional translation layer underneath: nested page tables, mapping what the guest believes are physical addresses onto real host physical memory. This double-translation is what lets several guests, each running an unmodified, standard OS memory manager, safely share one pool of actual physical RAM without any guest being able to see or address another guest's memory.

Synthetic devices: why virtualization doesn't mean full emulation

Early-generation virtualization commonly worked by emulating real hardware in software — presenting the guest with what looks like a real, specific physical network card or disk controller, with every low-level hardware detail faithfully reproduced. This works, but it's slow: every device interaction has to be trapped and interpreted by the hypervisor, replicating hardware behavior the guest OS was never actually designed to talk to efficiently in a virtualized context.

Modern Hyper-V instead offers synthetic devices and enlightened I/O, communicated over VMBus — a high-speed, purpose-built channel between guest and host specifically designed for virtualization, rather than for faithfully emulating physical hardware. A guest running Hyper-V's integration services talks to these synthetic devices directly, skipping the overhead of pretending to be real hardware entirely. This is exactly why a modern Generation 2 VM, using UEFI boot plus synthetic storage and network devices, boots and runs dramatically faster than an older, fully-emulated configuration — the difference isn't incidental optimization, it's a fundamentally more efficient communication path.

A worked example: why Task Manager shows "Virtual machine" workloads distinctly

Modern Windows exposes visibility into virtualization activity directly in Task Manager and Performance Monitor, distinguishing time spent servicing guest partitions from ordinary host workload — a direct, visible consequence of the fact that the hypervisor is genuinely scheduling separate virtual CPU contexts, not merely running guest code as an ordinary host process. This visibility is also exactly why enabling certain security features that depend on the hypervisor (covered in the next chapter) can show up as a small, measurable amount of always-on virtualization overhead, even when you haven't deliberately started any virtual machine yourself.

A common mistake

Assuming every VM necessarily runs at something close to full hardware-emulation overhead misreads two decades of virtualization technology evolution. The synthetic-device, VMBus-based model described in this chapter is specifically why well-configured modern virtual machines can run close to native speed for I/O-heavy workloads — the historical reputation of virtualization as inherently slow largely describes older, fully-emulated configurations, not how a properly-configured Generation 2 Hyper-V guest actually performs today.

Where this connects

• Plug and Play & power covers the device-stack machinery synthetic devices ultimately plug into, from the guest OS's own point of view.
• VBS, HVCI & isolation builds directly on the partition-isolation mechanism described here, repurposed for host-security rather than guest-OS hosting.