A hypervisor, also called a virtual machine monitor, is the software layer that creates, runs and isolates virtual machines on a physical host, dividing its CPU, memory, storage and network among several guest operating systems. In virtualization, it is the component that makes each guest believe it owns real hardware while preventing it from touching the hardware or memory of other guests.
Hypervisors are the foundation of most cloud computing: public cloud instances, private cloud clusters and developer desktops all depend on one. Modern hypervisors rely on hardware virtualization extensions in the processor, Intel VT-x or AMD-V, together with second-level address translation, so that guest code runs at close to native speed.
How a hypervisor virtualizes hardware
Guest code runs directly on the physical CPU for most instructions. When a guest executes a privileged operation, such as changing page tables or accessing a device, the processor traps to the hypervisor in an event called a VM exit. The hypervisor emulates or validates the operation and then resumes the guest.
Memory is virtualized with nested page tables, named EPT on Intel and NPT on AMD, which translate guest physical addresses to host physical addresses in hardware. Devices are provided through emulation, paravirtualized drivers such as virtio, or direct passthrough of a physical device to one guest.
The table summarizes how each hardware resource is shared.
| Resource | Virtualization technique | Guest sees |
|---|---|---|
| CPU | Scheduling vCPUs onto physical cores | A number of virtual processors |
| Memory | Nested page tables, ballooning, page sharing | Contiguous private RAM |
| Storage | Virtual disk files or volumes | A local disk controller |
| Network | Virtual switches and virtual NICs | One or more network adapters |
| Devices | Emulation, virtio or PCI passthrough | Standard or paravirtual hardware |
Type 1 and type 2 hypervisors
Hypervisors are classically divided by where they run relative to the host operating system. The distinction affects performance, security surface and typical use.
| Property | Type 1, bare metal | Type 2, hosted |
|---|---|---|
| Runs on | Directly on the hardware | As an application on a host OS |
| Examples | VMware ESXi, Microsoft Hyper-V, Xen, KVM | VirtualBox, VMware Workstation, Parallels Desktop |
| Overhead | Low | Higher, shares resources with the host OS |
| Attack surface | Small, dedicated to virtualization | Includes the full desktop OS |
| Typical use | Data centers and cloud | Development, testing, desktop labs |
The boundary is not always sharp. KVM turns the Linux kernel itself into a hypervisor, so it behaves as type 1 even though a general-purpose OS is present, and Hyper-V moves Windows into a privileged partition above the hypervisor.
Hypervisor features used in cloud operations
Beyond running guests, a production hypervisor provides management features that make virtual machines easier to operate than physical servers.
| Feature | What it does | Main caution |
|---|---|---|
| Live migration | Moves a running VM to another host with a pause of milliseconds | Needs shared or replicated storage and a fast network |
| VM snapshot | Captures disk and optionally memory state | Long-lived snapshots slow disks and grow large |
| Overcommitment | Allocates more vCPUs or RAM than physically present | Contention and swapping under load |
| Nested virtualization | Runs a hypervisor inside a guest | Additional overhead, used mainly for labs and CI |
| Resource limits and shares | Caps or prioritizes CPU and I/O per VM | Misconfiguration starves important guests |
vCPU overcommitment ratios of around 2 to 4 vCPUs per physical core are common for general workloads, while latency-sensitive databases are often given a 1 to 1 ratio. Memory overcommitment is riskier, because a host that runs short of RAM must swap guest memory to disk.
Hypervisors compared with container runtimes
Containers also isolate workloads, but they share the host kernel instead of virtualizing hardware. The two approaches are often combined, with containers running inside virtual machines.
| Aspect | Hypervisor with VMs | Container runtime |
|---|---|---|
| Isolation boundary | Virtual hardware, separate kernels | Kernel namespaces and cgroups |
| Guest OS | Any supported OS, including Windows | Same kernel family as the host |
| Startup time | Seconds to minutes | Typically under a second |
| Density per host | Tens of VMs | Hundreds of containers |
| Security strength | Stronger, smaller shared surface | Weaker, a kernel flaw affects all |
Lightweight microVM hypervisors such as Firecracker narrow this gap by starting minimal virtual machines in a fraction of a second, which is why they are used for serverless functions that need strong isolation between tenants.
Risks and common mistakes
- Noisy neighbors: one guest saturating CPU, disk or network degrades others on the same host unless limits are set.
- Excessive overcommitment produces high CPU ready time and unpredictable latency.
- Unpatched hypervisors are high-value targets, because a VM escape compromises every guest on the host.
- Snapshots used as backups remain on the same storage and disappear with it.
- All replicas on one host turn a single hypervisor failure into an application outage; anti-affinity rules prevent it.
A non-technical view
Picture a large office building owned by one landlord. Instead of renting the whole building to one company, the landlord divides it into separate, locked offices, each with its own door, electricity meter and mailbox. Tenants work as if they had their own building and never see each other’s papers.
A hypervisor is that landlord for a computer. It divides one powerful machine into many independent virtual computers, keeps them apart and makes sure each gets its fair share of power and space.
A concrete example
A mid-sized manufacturing company replaces fourteen aging physical servers with a cluster of three hosts running a type 1 hypervisor, each with 32 cores and 512 GB of RAM. The administrators create virtual machines for the ERP database, file services, domain controllers and several small applications, giving the database dedicated vCPUs at a 1 to 1 ratio and allowing moderate overcommitment for the rest.
Anti-affinity rules keep the two domain controllers on different hosts. When one host needs a firmware update, its virtual machines are live migrated to the other two hosts during working hours without users noticing. The company cuts its rack space and power use substantially and gains the ability to perform hardware maintenance without downtime.