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), and a 2 vCPU, 4 GiB sandbox costs $0.03125 an hour while it waits (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 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).
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).
Related: hypervisor, Firecracker, microVM, QEMU vs Firecracker.
Sources
Checked 25 September 2026.
- KVM main page, linux-kvm.org
- The Definitive KVM API Documentation, kernel.org
- KVM documentation index, kernel.org
- Firecracker getting started
Facts on this page were checked on 25 September 2026.