# What is KVM?

KVM (Kernel-based Virtual Machine) is the hypervisor built into Linux. It runs
guests on the CPU's virtualization extensions.

**You never touch KVM. Every Runtime sandbox still sits behind this hardware
boundary.** Each sandbox is a Firecracker microVM, and Firecracker runs its
guests on KVM. A 2 vCPU, 4 GiB sandbox costs $0.03125 an hour while it
sits idle ([pricing](/docs/pricing)).

## How does KVM work?

KVM is a kernel module, not a complete virtualization product. The project
describes it as "a loadable kernel module, kvm.ko, that provides the core
virtualization infrastructure and a processor specific module, kvm-intel.ko or
kvm-amd.ko." KVM requires a processor with Intel VT or AMD-V.

A program controls KVM through file descriptors. The kernel's API documentation
says that an `open("/dev/kvm")` "obtains a handle to the kvm subsystem". From
that handle, `KVM_CREATE_VM` returns a descriptor for one virtual machine.
`KVM_CREATE_VCPU` adds virtual processors to that machine. A thread then calls
`KVM_RUN` to execute guest code on a vCPU. It keeps running until the guest
needs something that the kernel leaves to user space, such as a device access.

For this reason, KVM always works with a companion program. QEMU, Firecracker
and Cloud Hypervisor are examples. Each one lays out guest memory, emulates
devices and loops on `KVM_RUN`. The page on
[virtual machine monitors](/glossary/virtual-machine-monitor) covers that half.

## Facts

| Property          | KVM, as its documentation states it                           |
| ----------------- | ------------------------------------------------------------- |
| Full name         | Kernel-based Virtual Machine                                  |
| In mainline Linux | Since 2.6.20                                                  |
| Kernel modules    | `kvm.ko`, plus `kvm-intel.ko` or `kvm-amd.ko` on x86          |
| Interface         | `/dev/kvm` and ioctls at system, VM, vCPU and device level    |
| Hardware          | Intel VT or AMD-V on x86; kernel docs also cover Arm and s390 |
| User-space side   | QEMU (mainline since 1.3), Firecracker, Cloud Hypervisor      |
| Access            | Firecracker needs read and write access to `/dev/kvm`         |

## Why KVM matters for AI agent sandboxes

Code that an agent writes is untrusted. With KVM underneath, that code runs
against a guest kernel on virtual processors. It does not run directly against
the host kernel's full set of system calls. A kernel bug that the code triggers
affects the guest. This is the boundary that separates a microVM from a
container, which shares the host kernel (see
[microVM vs container](/compare/microvm-vs-container)).

## How Runtime relates to KVM

Runtime operates the servers, the KVM hosts and the Firecracker processes. You
never grant anyone access to `/dev/kvm`, and you never pick a kernel. You get
the result: a sandbox with its own Linux kernel and disk, and `sudo` inside it.
CPU, memory, network rules and cost are enforced on the host. Root in the guest
cannot reach them ([security](/docs/security#root-inside-the-sandbox)).

Related: [hypervisor](/glossary/hypervisor),
[Firecracker](/glossary/firecracker), [microVM](/glossary/microvm),
[QEMU vs Firecracker](/compare/qemu-vs-firecracker).

## Sources

Checked 25 October 2026.

- [KVM main page, linux-kvm.org](https://www.linux-kvm.org/page/Main_Page)
- [The Definitive KVM API Documentation, kernel.org](https://docs.kernel.org/virt/kvm/api.html)
- [KVM documentation index, kernel.org](https://docs.kernel.org/virt/kvm/index.html)
- [Firecracker getting started](https://github.com/firecracker-microvm/firecracker/blob/main/docs/getting-started.md)

Facts on this page were checked on 25 October 2026.