A VMM, or virtual machine monitor, is software that sits between physical hardware and one or more operating systems, giving each OS the illusion that it has full control of the machine. In practice, the VMM is the one actually in charge, dividing up the computer’s processor, memory, and storage among multiple virtual machines running simultaneously. You’ll also hear VMMs called hypervisors, and they’re the foundational technology behind cloud computing, server consolidation, and the virtual machines developers spin up on their laptops.
How a VMM Works
Think of a VMM as an operating system for operating systems. A normal OS manages applications and decides how they share hardware. A VMM does the same thing one level down: it manages entire operating systems and decides how they share the same physical machine. Each OS runs inside its own virtual machine, believing it has dedicated processors, memory, and storage. Behind the scenes, the VMM intercepts key hardware interactions and redirects them so nothing collides.
The core technique is called limited direct execution. Most of the time, the guest operating system’s code runs directly on the real CPU at full speed. But when it tries to do something sensitive, like accessing memory that belongs to another virtual machine or talking to a hardware device, the processor traps the instruction and hands control to the VMM. The VMM handles the request safely, then returns control. This happens thousands of times per second, fast enough that the guest OS never notices it isn’t running alone.
Unlike a regular operating system, a VMM isn’t trying to make hardware easier to use. It doesn’t provide friendly file systems or windowing interfaces. Its job is purely to replicate the hardware environment faithfully enough that each guest OS can run unmodified.
Type 1 vs. Type 2 Hypervisors
VMMs come in two architectural flavors, and the distinction matters for performance.
A Type 1 (bare-metal) hypervisor installs directly on the physical hardware with no operating system underneath it. It negotiates directly with the CPU, memory, and storage devices to allocate dedicated resources to each virtual machine. Because there’s no middleman OS, Type 1 hypervisors are faster and provide stronger isolation between virtual machines. This is what runs in data centers and cloud platforms. VMware ESXi, Microsoft Hyper-V, and Xen are common examples.
A Type 2 (hosted) hypervisor runs as an application on top of a conventional operating system like Windows, macOS, or Linux. When a virtual machine needs resources, the hypervisor has to ask the host OS, which then talks to the hardware. That extra layer makes things slower and less efficient, since the hypervisor can only use whatever resources the host OS is willing to hand over. VirtualBox and VMware Workstation are typical Type 2 hypervisors. They’re popular for development, testing, and running a second OS on your personal computer, where raw performance matters less than convenience.
The Performance Cost of Virtualization
Running through a VMM is never quite as fast as running on bare metal, but the penalty varies dramatically depending on what you’re doing. CPU-intensive tasks typically see 10 to 20 percent overhead, because most arithmetic and logic instructions still execute directly on the processor. The VMM only intervenes for privileged operations.
Storage and networking take a bigger hit. Research comparing virtual machines to physical machines found roughly 30 percent lower data throughput for disk operations and over 55 percent overhead for network communication in some configurations. These numbers explain why so much engineering effort goes into reducing I/O overhead in virtualized environments.
Hardware Support for Virtualization
Modern processors include dedicated circuitry specifically designed to make VMMs faster and more secure. Intel calls its version VT-x; AMD calls its AMD-V. These instruction sets let the CPU run virtual machine code in a dedicated, isolated context without the VMM needing to intercept and translate every sensitive instruction in software.
Before hardware-assisted virtualization existed, VMMs had to use complex software tricks to catch and emulate privileged instructions, which was slow and fragile. With VT-x or AMD-V enabled, the processor itself handles the separation between virtual machines, managing memory address translation and preventing one VM from touching another’s resources at the hardware level. Some modern hypervisors, like VirtualBox from version 6.1 onward, won’t even run without these features because reimplementing them in software is no longer worth the effort.
These features are built into nearly every Intel and AMD processor sold today but are sometimes disabled by default in the BIOS. If you’ve ever tried to start a virtual machine and gotten an error about virtualization not being enabled, this is why.
How VMMs Handle Devices
Sharing a CPU among virtual machines is relatively straightforward because processors were designed for time-slicing. Sharing physical devices like network cards and storage controllers is harder. VMMs use a few different approaches.
The simplest method is full emulation: the VMM presents each virtual machine with a fake version of a common device and translates every interaction into real hardware commands. This works broadly but adds latency. A more efficient approach uses paravirtual drivers, where the guest OS knows it’s virtualized and uses a streamlined communication channel to talk to the VMM instead of pretending a real device exists.
For the highest performance, a technology called SR-IOV lets a single physical device (typically a network card) present itself as many independent virtual devices on the hardware bus. Each virtual machine gets its own virtual function with dedicated resources, effectively talking to the hardware directly without the VMM in the middle. High-end network adapters can expose over 100 virtual functions per port, which is how cloud providers deliver near-native network performance to their customers’ virtual machines.
Where VMMs Came From
The concept dates back to the 1960s. IBM’s CP/67 system, running on the System/360 Model 67, created multiple “virtual computers” so that each user at a terminal could operate as though they had an entire machine to themselves. The system used a hardware relocation device to map memory addresses, swapping 4,096-byte pages between physical memory and secondary storage (drums and disks) as needed. This is recognizably the same paging technique that modern VMMs and operating systems still use today.
The key innovation was separating the multiprogramming function (keeping multiple users from interfering with each other) from data management (file systems and I/O). Earlier IBM operating systems combined these responsibilities, but CP/67 kept them apart, creating a cleaner abstraction that let each virtual machine run its own choice of software. That architectural insight carried forward through IBM’s VM operating system in the 1970s and eventually into the VMware and Xen hypervisors that launched the modern virtualization era in the early 2000s.
VMMs vs. Containers
Containers (like Docker) are often mentioned alongside VMMs, but they solve a different problem. A VMM virtualizes an entire machine, including its own OS kernel, device drivers, and system libraries. A container shares the host’s OS kernel and only isolates the application and its dependencies. This makes containers far lighter: they start in seconds, use less memory, and introduce minimal performance overhead (around 2 percent for storage, compared to over 30 percent for a full VM in one benchmark).
The tradeoff is isolation. Because containers share a kernel, a vulnerability in that kernel can potentially affect every container on the host. Virtual machines, each running their own kernel behind a VMM, are more thoroughly separated. In practice, many organizations use both: VMs for strong isolation between tenants or security boundaries, and containers within those VMs for efficiently packaging and deploying applications.