Hypervisor Types & Comparison
Compare the major hypervisors and VM-isolation technologies side by side — KVM, Xen, VMware ESXi, Microsoft Hyper-V, QEMU, Proxmox, Firecracker, gVisor, Kata Containers and AWS Nitro — organised by the Type 1 (bare-metal) vs Type 2 (hosted) vs microVM vs sandbox taxonomy. Each entry shows its isolation model, where the trust boundary sits, the real attack surface, and notable historical vulnerabilities. Everything runs in your browser.
Hypervisor runs directly on the hardware.
Hypervisor runs as a program on a host OS.
A stripped-down VM with a tiny device model.
Isolation without a full VM — intercept or re-implement the kernel.
| Vendor / origin | Typical use | |||
|---|---|---|---|---|
AWS Nitro | Bare-metal | Amazon Web Services 2017 | Proprietary | The foundation of modern Amazon EC2 instances and the basis for Nitro Enclaves (isolated compute for sensitive data). |
KVM | Bare-metal | Linux kernel community / Red Hat Merged into Linux 2.6.20, 2007 | Open source | The virtualization engine under most Linux clouds, OpenStack, Proxmox, oVirt/RHV and the major public clouds. The default Linux hypervisor. |
Microsoft Hyper-V | Bare-metal | Microsoft Windows Server 2008 | Proprietary | Windows Server virtualization, Azure (a customized Hyper-V), and client Hyper-V for Windows Sandbox, WSL2 and developer VMs. |
Proxmox VE | Bare-metal | Proxmox Server Solutions 2008 | Open source | SMB and home-lab virtualization, hyperconverged clusters with Ceph/ZFS, and self-hosted private clouds that want a free alternative to vSphere. |
VMware ESXi | Bare-metal | VMware (Broadcom) ESX 2001, ESXi 2007 | Proprietary | Enterprise private clouds and data centers, managed via vCenter/vSphere. Common in VDI and consolidation projects. |
Xen | Bare-metal | Xen Project (Linux Foundation) University of Cambridge, 2003 | Open source | Historically the engine behind large clouds (notably early AWS EC2) and still used in Citrix Hypervisor, QubesOS and telco/edge deployments. |
QEMU | Hosted | QEMU project Fabrice Bellard, 2003 | Open source | The device model for KVM-based stacks, cross-architecture emulation, firmware/OS development and CI. Almost every Linux VM touches QEMU somewhere. |
Firecracker | microVM | Amazon Web Services Open-sourced 2018 | Open source | The isolation layer under AWS Lambda and AWS Fargate, and a popular backend for sandboxing untrusted code and functions. |
Kata Containers | microVM | OpenInfra Foundation 2017 (from Intel Clear Containers + Hyper runV) | Open source | Kubernetes multi-tenancy and untrusted-workload isolation where a shared-kernel container is considered too weak. |
gVisor | Sandbox | Google Open-sourced 2018 | Open source | Hardening container isolation (runsc OCI runtime), notably under Google Cloud Run / GKE Sandbox and for running untrusted code. |
Vulnerabilities are described at the class level or via well-known public CVEs (VENOM = CVE-2015-3456; L1TF/Foreshadow = CVE-2018-3646). This is an educational comparison — always check the current advisory for any product before you rely on it.
What this tool is
- A free, in-browser comparison of 10 hypervisors and VM-isolation technologies — KVM, Xen, VMware ESXi, Microsoft Hyper-V, QEMU, Proxmox, Firecracker, gVisor, Kata Containers and AWS Nitro.
- A hypervisor is the software layer that creates and runs virtual machines, giving each guest its own virtual CPU, memory and devices while keeping them isolated from one another and from the host.
- Type 1 (bare-metal) runs directly on hardware with a tiny trusted base (ESXi, Xen, Hyper-V, KVM); Type 2 (hosted) runs as an app on a full host OS (QEMU alone, desktop VM apps); microVMs (Firecracker) and sandboxes (gVisor, Kata) target serverless and container isolation.
- Each entry lists the isolation model, the attack surface, and real historical vulnerabilities (e.g. VENOM, CVE-2015-3456, in the QEMU device model; L1TF/Foreshadow, CVE-2018-3646, a cross-VM CPU side channel).
- The real guest-to-host attack surface is the device-emulation code and the shared host kernel — not the thin hypervisor core — which is why "remove unused emulated devices" and "patch the host kernel" are the foundational hardening rules.
What is a hypervisor?
A hypervisor (or virtual machine monitor) is the software that creates and runs virtual machines. It gives each guest its own virtual CPU, memory and devices, schedules those onto the real hardware, and — most importantly for security — enforces isolation so one VM cannot read another VM's memory or reach the host. Modern CPUs provide virtualization extensions (Intel VT-x, AMD-V) so guest code runs on the real processor at near-native speed, with the hypervisor intervening only for privileged operations.
Type 1 vs Type 2
A Type 1 (bare-metal) hypervisor runs directly on the hardware with no general-purpose OS beneath it — at most a thin privileged control domain (Xen's dom0, the ESXi VMkernel, the Hyper-V parent partition). ESXi, Xen, Hyper-V and KVM are Type 1, and because the trusted base is small it is the standard for servers and the cloud. A Type 2 (hosted) hypervisor runs as an ordinary application on a full host OS (QEMU on its own, desktop VM apps); it is convenient for laptops and labs, but the whole host OS becomes part of the attack surface.
Where the trust boundary really is
The thin hypervisor core is rarely where guests escape. In practice the dangerous surface is the device-emulation code — every virtual NIC, disk, graphics adapter or legacy controller is software parsing guest-controlled input — and the shared host kernel and CPU. VENOM (CVE-2015-3456) was a flaw in QEMU's virtual floppy controller that was reachable even when no floppy was configured; that single bug affected every VMM embedding that code. CPU side channels like L1TF/Foreshadow (CVE-2018-3646), MDS and the Spectre/Meltdown family can leak data across VM boundaries unless the host applies mitigations. This is why the two foundational hardening rules are "remove unused emulated devices" and "patch the host kernel and microcode".
VM isolation vs shared-kernel containers
A VM boundary is enforced by hardware and the hypervisor; each VM has its own kernel. A container shares the host kernel and is isolated only by kernel features (namespaces, cgroups, seccomp), so one host-kernel bug can breach it. That gap is the reason microVMs (Firecracker, Cloud Hypervisor) and Kata Containers wrap workloads in lightweight VMs, and gVisor runs a user-space kernel that intercepts syscalls — all to give container ergonomics with a stronger boundary for untrusted, multi-tenant code.
Keep in mind: the host kernel is shared by every guest. In 2026, researchers reported a Linux-kernel networking issue (around IPv4 checksum handling) with potential cross-boundary impact for some sandbox/VM setups; verification was still ongoing, so no specific CVE number is asserted here. The evergreen lesson is the same — host-kernel patching is part of hypervisor security, not separate from it.
Frequently asked questions
What is a hypervisor?
A hypervisor (also called a virtual machine monitor, or VMM) is the software layer that creates and runs virtual machines. It sits between physical hardware and one or more guest operating systems, giving each guest its own virtual CPU, memory, storage and network devices, and scheduling those virtual resources onto the real hardware. Crucially, it enforces isolation: one VM should not be able to read the memory of another VM or of the host. Modern hypervisors use CPU virtualization extensions (Intel VT-x, AMD-V) so guest code runs on the real processor at near-native speed, with the hypervisor stepping in only for privileged operations.
What is the difference between a Type 1 and a Type 2 hypervisor?
A Type 1 (native or bare-metal) hypervisor runs directly on the hardware with no general-purpose operating system beneath it — at most a thin privileged control domain. VMware ESXi, Xen, Microsoft Hyper-V and KVM are Type 1. Because the trusted computing base is small and purpose-built, Type 1 is the standard for servers and the cloud. A Type 2 (hosted) hypervisor runs as an application on top of a conventional OS (Linux, Windows, macOS); the host OS owns the hardware and the hypervisor asks it for resources. QEMU on its own, and desktop VM apps, are Type 2. Type 2 is convenient for laptops and labs, but the entire host OS is part of the attack surface, so the trusted base is much larger.
Is KVM a Type 1 or Type 2 hypervisor?
KVM is generally classified as Type 1, with an asterisk. KVM is a Linux kernel module that turns the host Linux kernel itself into a bare-metal hypervisor using hardware virtualization — guest code runs directly on the CPU, not emulated, which is the hallmark of Type 1. The nuance is that KVM relies on a full Linux system around it (and a user-space VMM such as QEMU for the device model), so some people call it a hybrid or argue it behaves like Type 2. The practical answer: KVM provides Type 1-class performance and isolation, and it is the engine under most Linux clouds and under platforms like Proxmox, Firecracker and Kata Containers.
What is the difference between VM isolation and container isolation?
A virtual machine is isolated by the hardware and the hypervisor: each VM has its own guest kernel, and the CPU enforces the boundary between guests, so a VM escape requires defeating the hypervisor or the silicon. Containers share the host kernel — isolation is enforced by kernel features (namespaces, cgroups, seccomp, capabilities), so a single host-kernel vulnerability can let a container escape to the host or to a sibling container. VMs are therefore the stronger boundary for untrusted or multi-tenant workloads, at the cost of more overhead. The gap is why technologies like Firecracker and Kata Containers (lightweight VMs per workload) and gVisor (a user-space kernel that intercepts syscalls) exist: they give container-like ergonomics with a stronger, VM-like or syscall-filtered boundary.