What is a microVM? How it differs from containers and full VMs

01What is a microVM, in plain terms?

A microVM is an ordinary hardware-virtualized machine with almost everything optional removed. It still has its own guest kernel and its own memory, and the CPU's virtualization extensions still separate it from the host. What goes is the legacy hardware a general-purpose VM pretends to have: firmware, a full PCI bus, sound cards, USB controllers, graphics. The guest gets a few paravirtual devices for disk, network and a console, and little else.

The program that creates and runs the machine is the virtual machine monitor (VMM). On Linux the VMM asks the kernel's KVM interface to run the guest; a program opens /dev/kvm and drives the virtual machine with ioctls. On a Mac, Apple's Hypervisor and Virtualization frameworks fill that role. The VMM is what makes a VM micro: it emulates less, so there is less code an attacker in the guest can reach and less work to do at boot.

Firecracker, the VMM Amazon built for AWS Lambda and Fargate, is the best-known example. Its project page lists a boot time under 125 ms, under 5 MiB of memory overhead per VM and only 5 emulated devices. Cloud Hypervisor, a Rust VMM for cloud workloads with minimal emulation, follows the same idea, and QEMU ships a microvm machine type that its docs describe as inspired by Firecracker, without PCI or ACPI, and designed for short-lived guests.

02Where is the kernel boundary? A diagram in four lines

The clearest way to compare isolation designs is to follow one system call from the sandboxed program down to the hardware and note which kernel answers it. Read each line left to right; the host kernel is the one you are protecting.

The difference that matters for security is the second hop. In a container the first kernel the program reaches is the host's. In a microVM or a full VM it reaches a guest kernel that belongs to that sandbox alone, and an exploit has to break that kernel and then the VMM and the hypervisor before it touches the host.

• Container: program → host kernel (shared by every container on the machine) → hardware.
• gVisor: program → Sentry, a kernel written in Go running in user space → a narrow set of host kernel calls → hardware.
• MicroVM: program → its own guest kernel → a small VMM with a few virtual devices → KVM or Apple's hypervisor → hardware.
• Full VM: program → its own guest OS with firmware and a full device model → a general-purpose hypervisor → hardware.

03MicroVM vs container: what actually changes?

A container is a set of processes the host kernel keeps apart. Docker's security docs call kernel namespaces the first and most straightforward form of isolation, and describe control groups as resource accounting and limiting, adding that cgroups play no role in stopping one container from reaching another's data. Every container on a host runs on that one kernel, so a kernel bug reachable from inside a container is reachable from all of them.

A microVM gives each workload its own kernel. That costs more than a container: a kernel has to boot, memory is reserved per machine, and files shared from the host cross a virtual device instead of a bind mount. It buys a smaller and better-defined attack surface, and it lets the workload do things containers make awkward, such as loading kernel modules, running its own container engine or running as root without that meaning root on the host.

The two are not exclusive. Kata Containers runs ordinary OCI container images inside lightweight VMs and plugs into the Kubernetes CRI, so the workload looks like a container to the orchestrator and like a VM to the host.

04MicroVM vs full VM: what is left out, and what that costs

A full VM such as one you build in UTM, VirtualBox or a cloud console imitates a whole PC or server so that any operating system can install and run on it. A microVM drops that goal. It usually boots a Linux kernel directly, skips the firmware stage and offers only the devices Linux needs to run a workload.

Leaving things out has costs. Kata's hypervisor table marks only QEMU, its full-featured option, as supporting GPUs and confidential-computing technologies such as Intel TDX and AMD SEV-SNP; its Firecracker, Cloud Hypervisor, Dragonball and StratoVirt options are marked unsupported for all three. If you need a desktop, a GPU or a Windows guest, a full VM is usually the better tool.

05How fast does a microVM boot?

Fast enough that start-up rarely decides the design. Firecracker's project page states under 125 ms. Apple's Containerization package, which runs each Linux container in its own lightweight VM on Apple silicon, says its containers reach sub-second start times through an optimised kernel configuration and a minimal root filesystem. Those are each vendor's own figures on their own hardware, so measure your workload before you plan around them.

Boot time is mostly about the guest: a lean kernel and a small root filesystem start faster than a general-purpose distribution. Snapshots change the picture again. A VMM that can save a running machine's memory and restore it skips boot altogether, which is how services hand out a warm machine on request.

06Why do AI agents use microVMs?

An AI coding agent runs code nobody has read yet: commands it writes, packages it installs, scripts from a repository it just cloned. That is the workload microVMs were built for, and three properties make them a good fit. The agent's mistakes and any exploit land on a kernel that belongs to that sandbox alone. The guest is real Linux, so package managers, compilers, test runners and even a container engine behave as they do on a server. And the machine is cheap enough to give every agent, or every task, its own.

A microVM is a boundary, not a policy. It does not decide which hosts the agent may reach, where API keys live, which folder it may see or how to undo a bad change. Those come from the sandbox built around the VM, and they matter as much as the kernel boundary when the threat is a prompt-injected agent sending your data out.