How Virtual Machines and Hypervisors Actually Work

Quick Answer

A hypervisor is the software layer that creates virtual machines by carving one physical computer's CPU, memory, and I/O into isolated slices, each running its own full guest operating system with its own kernel. Type 1 hypervisors (VMware ESXi, Hyper-V, Xen, KVM) run directly on bare-metal hardware; Type 2 hypervisors (VirtualBox, VMware Workstation, Parallels) run as an application on top of a host OS. Hardware extensions like Intel VT-x and AMD-V do the work that makes this fast enough to use in production.

What a Hypervisor Actually Does

A hypervisor (also called a virtual machine monitor, or VMM) is the software layer that takes one physical computer and carves it into multiple isolated virtual computers. It does this for three resources at once: CPU, memory, and I/O. For CPU, it schedules multiple guest operating systems onto the physical cores, either time-slicing a core across several guests or pinning specific cores to specific guests. For memory, it maintains a translation between the memory addresses a guest OS thinks it owns (guest physical addresses) and where that memory actually lives on the real hardware (host physical addresses). For I/O, it either emulates virtual hardware devices in software (a virtual disk controller, a virtual NIC) or arranges for the guest to talk to real hardware more directly.

The one thing to hold onto through this whole post: each virtual machine believes it owns a real, complete computer, and runs its own full operating system, with its own kernel, from boot. That's the entire architectural difference from a container, which we won't re-explain in depth here since this site already covers Docker and container images elsewhere — but it's worth stating plainly, because it's the fact everything else in this post follows from: a VM's isolation boundary is a full second kernel; a container's isolation boundary is a set of restrictions applied to processes that are still running on the one kernel the host already has.

Type 1 (Bare-Metal) vs Type 2 (Hosted) Hypervisors

A Type 1 hypervisor runs directly on the physical hardware, with no general-purpose host operating system underneath it. It has direct access to CPU, memory, and devices, and everything else — including a management console, if there is one — runs as a guest on top of it, not the other way around. VMware ESXi, Microsoft Hyper-V, and Xen are standard examples; KVM is an interesting edge case, since it's built directly into the Linux kernel, which effectively turns a Linux host itself into a Type 1 hypervisor once KVM is loaded. This is the category almost all production server virtualization and public cloud infrastructure runs on, because direct hardware access means less overhead, and not depending on a general-purpose OS underneath means a smaller, more auditable attack surface.

A Type 2 hypervisor runs as an ordinary application on top of a regular host operating system — Windows, macOS, or Linux — the same way a browser or an IDE does. VirtualBox, VMware Workstation, and Parallels Desktop are the standard examples. Because it's just an app, it has to go through the host OS for device drivers and share the machine's resources with everything else the host is running, which adds a layer of overhead a Type 1 hypervisor doesn't have. In exchange, it's trivial to install and use — which is exactly why Type 2 hypervisors are the ones developers run on their own laptops for a local test VM, and why they're rarely the choice for production infrastructure.

Why VT-x and AMD-V Exist: x86 Wasn't Built to Be Virtualized

Here's the history that explains why these CPU extensions exist at all. The x86 instruction set wasn't originally designed with virtualization in mind, and it has certain privileged instructions that behave differently — instead of cleanly failing — when run at a lower privilege level than they expect. That meant early x86 virtualization (software-only, pre-2005) had to work around the CPU rather than with it: either through binary translation, rewriting a guest's privileged instructions on the fly in software before they executed, or through paravirtualization, where the guest OS itself is modified to know it's virtualized and call the hypervisor directly instead of issuing the problematic privileged instructions at all — this was Xen's original approach.

Intel's VT-x and AMD's AMD-V, introduced in the mid-2000s, fixed this at the hardware level instead. They add a new CPU operating mode — often described as 'root' and 'non-root' operation, informally 'Ring -1' — so the hypervisor runs at the more privileged root level, while the guest operating system's kernel can run completely unmodified at its normal Ring 0. The CPU itself automatically traps out to the hypervisor only when the guest tries to do something that genuinely needs arbitration (touching real hardware, for instance), instead of the hypervisor needing to rewrite the guest's code ahead of time. A second wave of hardware assistance followed for memory specifically: Intel's Extended Page Tables (EPT) and AMD's Rapid Virtualization Indexing (RVI) let the CPU's memory-management unit walk the guest-to-host address translation directly in hardware. Before that, hypervisors maintained this translation themselves in software using 'shadow page tables' — a technique that published virtualization research puts at roughly 10-20% memory overhead with a 300-500 cycle penalty on every TLB miss, versus under 2% memory overhead and a 100-150 cycle penalty with hardware-assisted EPT/RVI. That gap is most of the reason virtualization went from 'noticeably slow' to 'good enough for production' in the mid-to-late 2000s.

How Much Performance Do You Actually Lose Running a VM?

It's tempting to want one clean number here, and the honest answer is that it depends heavily on the workload — but with modern hardware-assisted virtualization (VT-x/AMD-V plus EPT/RVI), published benchmarking research generally puts raw CPU overhead in the low single digits, commonly cited around 2-5% versus bare metal, with memory bandwidth reduced by roughly 4-5% and memory latency increased by roughly 4-9%. That's a dramatic improvement over the software-only virtualization era, where overhead — especially for anything memory-management-heavy — could be far higher.

The workload matters more than the average number does. Pure CPU-bound compute is the cheapest thing to virtualize, because the guest mostly just runs, uninterrupted, on real cores. Interrupt-heavy, I/O-heavy workloads — fast networking, NVMe storage under heavy load — pay the highest tax, because every device interaction is a potential trap out to the hypervisor and back. That's the actual reason technologies like SR-IOV exist: they let a VM talk to a dedicated hardware slice of a physical NIC directly, bypassing the hypervisor for the data path entirely, specifically because that's where virtualization overhead concentrates.

VMs vs Containers: The Difference That Actually Matters

Without re-explaining how containers work internally — this site has dedicated posts on Docker for that — here's the contrast that's worth being precise about. A VM virtualizes hardware, and each VM boots a genuinely separate, independent operating system kernel. Ten VMs on one host means ten kernels, ten independent copies of the OS's own memory footprint, and a real (virtual) boot sequence for each one that takes real seconds. A container virtualizes at the operating-system level instead: every container on a host shares the exact same running kernel the host itself is using. Starting a container is just starting a process — milliseconds, not seconds — but the trade is that every container is permanently stuck using that one shared kernel.

That single fact explains two things people run into constantly without necessarily connecting them to it. First, why 'which container base image' is a much smaller decision than 'which guest OS' for a VM — the container image never has to bring its own kernel, just userspace files. Second, why a full Windows guest can run inside a hypervisor on a Linux host without issue (the guest brings its own complete kernel along), but a Linux container fundamentally cannot run natively on a Windows kernel and vice versa. If you've ever run Docker Desktop on Windows or Mac, there's a real Linux VM quietly running underneath it doing exactly this job — every 'Linux container' on your Mac is actually running inside a hidden Linux kernel, inside a hypervisor, on your non-Linux laptop.

Where This Shows Up in the Cloud You Already Use

Every VM instance you rent from a public cloud provider — an AWS EC2 instance, a Google Compute Engine instance, an Azure VM — is itself a guest running under a Type 1 hypervisor on physical hardware you'll never see or touch. AWS's own infrastructure runs on the Nitro Hypervisor, a stripped-down, KVM-derived hypervisor purpose-built for their fleet; Google Compute Engine runs its instances on KVM directly. When you provision a cloud VM, you are, quite literally, renting a slice of somebody else's Type 1 hypervisor.

One practical gotcha worth knowing before you hit it yourself: nested virtualization — running a hypervisor inside a VM, which you need for things like a CI pipeline that builds VM images, or running VirtualBox or WSL2 inside a cloud VM for testing — requires the outer hypervisor to expose the CPU's virtualization extensions through to the inner guest. Not every cloud instance type or configuration allows this, and finding that out mid-setup is a genuinely common way to lose an afternoon.

Frequently Asked Questions