# What is KVM?

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

**Every Runtime sandbox sits behind this hardware boundary without you touching
KVM at all.** Each sandbox is a Firecracker microVM, and Firecracker runs its
guests on KVM. A new sandbox ran its first Python command 351 ms after the
create request at the median, measured on 24 September 2026
([speed](/docs/speed)), and a 2 vCPU, 4 GiB sandbox costs $0.03125 an hour
while it waits ([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." It needs processors with Intel VT or AMD-V.

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

That split is why KVM always travels with a companion program. QEMU,
Firecracker and Cloud Hypervisor are such programs: 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 an agent writes is untrusted. With KVM underneath, that code runs against
a guest kernel on virtual processors, not against the host kernel's full
system-call surface. A kernel bug the code triggers lands in 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, so
you never grant anyone access to `/dev/kvm` or pick a kernel. You get the
result: a sandbox with its own Linux kernel and disk, `sudo` inside, and CPU,
memory, network rules and cost enforced on the host where 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 September 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 September 2026.