# What Is a MicroVM, and How Is It Different From a Container or a VM?

> A microVM is a virtual machine run by a minimal virtual machine monitor, such as Firecracker or Cloud Hypervisor, on Linux KVM. It boots its own guest kernel, sees a handful of paravirtualized virtio devices instead of an emulated PC, and gets hardware isolation with far less boot time and memory than a full VM.

Source: https://sandboxer.com/guides/what-is-a-microvm. Updated 2026-10-27.

**Short answer:** A microVM is a virtual machine run by a minimal virtual machine monitor, such as Firecracker or Cloud Hypervisor, on Linux KVM. It boots its own guest kernel, sees a handful of paravirtualized virtio devices instead of an emulated PC, and gets hardware isolation with far less boot time and memory than a full VM.

## The definition, part by part

A microVM is four things together:

1. **KVM does the isolation.** KVM is the Linux kernel's hypervisor. A user-space program drives it through ioctls on three kinds of file descriptors: system, VM and vCPU ([KVM API](https://docs.kernel.org/virt/kvm/api.html)). The CPU's virtualization extensions keep the guest's memory and instructions apart from the host.
2. **A minimal VMM is the user-space program.** Firecracker "uses the Linux Kernel Virtual Machine (KVM) to create and run microVMs" and "excludes unnecessary devices and guest-facing functionality to reduce the memory footprint and attack surface area of each microVM" ([Firecracker README](https://github.com/firecracker-microvm/firecracker/blob/main/README.md)). Cloud Hypervisor lists "minimal emulation" as a goal and "runs on top of the KVM hypervisor and the Microsoft Hypervisor (MSHV)" ([Cloud Hypervisor README](https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/README.md)).
3. **Virtio devices instead of emulated hardware.** The guest's disk, network and other I/O go through paravirtualized virtio devices. Cloud Hypervisor expects "most I/O handled by paravirtualised devices (e.g. virtio)" with "no requirement for legacy devices". Firecracker presents virtio over MMIO by default; Cloud Hypervisor supports only the virtio-pci transport ([device model](https://github.com/cloud-hypervisor/cloud-hypervisor/blob/main/docs/device_model.md)).
4. **Its own guest kernel, often booted directly.** The VMM can load a Linux kernel image straight into memory (Cloud Hypervisor's `--kernel`, "direct kernel boot") instead of running BIOS or UEFI firmware and a bootloader first.

"MicroVM" is a design, not one product. QEMU even ships a `microvm` machine type, "inspired by Firecracker and constructed after its machine model", which it describes as "a minimalist machine type without PCI nor ACPI support, designed for short-lived guests" ([QEMU microvm](https://www.qemu.org/docs/master/system/i386/microvm.html)).

## MicroVM vs container vs full VM

| | Container | MicroVM | Full VM |
| - | - | - | - |
| What it is | A process tree in Linux namespaces and cgroups | A KVM guest run by a minimal VMM (Firecracker, Cloud Hypervisor) | A guest run by a general-purpose VMM that emulates a whole PC, such as QEMU with its `q35` or `pc` machine type |
| Boot path | No boot: the runtime starts a process on the running host kernel | VMM loads a kernel directly; no firmware or bootloader needed | Firmware (BIOS or UEFI), then a bootloader, then the kernel |
| Device model | The host's devices, filtered | A few virtio devices (block, net, vsock, entropy, balloon) and little or no legacy hardware | An emulated PC: chipset, USB, VGA, sound, IDE/SATA and more, plus virtio if configured |
| Kernel | Shared with the host | The guest's own | The guest's own, any OS the firmware can boot |
| Isolation boundary | The host kernel's system-call interface | Hardware virtualization plus a small VMM | Hardware virtualization plus a large emulator |
| Start time | Milliseconds (a process start) | Firecracker documents `<= 125 ms` to `/sbin/init` under stated conditions ([specification](https://github.com/firecracker-microvm/firecracker/blob/main/SPECIFICATION.md)) | Usually seconds, because firmware and bootloader run first |
| Memory overhead | Little beyond the processes | Firecracker documents `<= 5 MiB` of VMM overhead for a 1 vCPU, 128 MiB guest | Higher; depends on the emulator and the devices attached |

Which boundary fits untrusted code is a separate question, answered in [Container vs microVM for untrusted code](/guides/container-vs-microvm-for-untrusted-code). How the two main microVM VMMs differ is in [Firecracker vs Cloud Hypervisor](/guides/firecracker-vs-cloud-hypervisor).

## What a microVM looks like from the inside

A definition is easier to trust when you can check it. Every Sandboxer sandbox is a Cloud Hypervisor microVM, so we created a `small` one on production and ran these commands in it. The output below is real.

```bash
sbx new --name aeo-microvm-1 --type small
id=sb_omhuxdkjv6    # the id sbx new printed
```

### Its own kernel

```bash
sbx exec $id "uname -r"
```

```text
6.18.56-sandboxer
```

A container would report the host's kernel version here, because it has no kernel of its own. This guest runs a kernel built for it, separate from whatever the host runs.

### The hypervisor is KVM

```bash
sbx exec $id "systemd-detect-virt"
sbx exec $id "grep -m1 -o -w hypervisor /proc/cpuinfo"
```

```text
kvm
hypervisor
```

`systemd-detect-virt` prints `kvm` for a KVM guest (it prints a container name such as `docker` or `lxc` inside a container, and `none` on bare metal). The `hypervisor` CPU flag means the CPU the guest sees is a virtual one presented by a hypervisor. KVM also exposes a signature leaf, `0x40000000` with the string `KVMKVMKVM`, that guests use to find it ([KVM CPUID](https://docs.kernel.org/virt/kvm/x86/cpuid.html)).

### The VMM is Cloud Hypervisor

```bash
sbx exec $id "sudo dmesg | grep -i cloud"
```

```text
[    0.000000] DMI: Cloud Hypervisor cloud-hypervisor, BIOS 0
[    0.000173] ACPI: RSDP 0x00000000000A0000 000024 (v02 CLOUDH)
[    0.000175] ACPI: XSDT 0x00000000000A1469 00003C (v01 CLOUDH CHXSDT   00000001 RVAT 01000000)
[    0.000177] ACPI: FACP 0x00000000000A12B7 000114 (v06 CLOUDH CHFACP   00000001 RVAT 01000000)
…
```

The machine's DMI vendor is `Cloud Hypervisor`, and the ACPI tables were written by the VMM (`CLOUDH`), not by a firmware vendor. `BIOS 0` and the lack of `/sys/firmware/efi` fit direct kernel boot. The same boot log also shows the kernel noticing KVM in its first instant:

```text
[    0.000000] Hypervisor detected: KVM
[    0.009657] Booting paravirtualized kernel on KVM
```

### The devices are virtio, and there are few of them

```bash
sbx exec $id 'for d in /sys/bus/virtio/devices/*; do echo "$(basename $d) device=$(cat $d/device) driver=$(basename $(readlink $d/driver))"; done'
```

```text
virtio0 device=0x0002 driver=virtio_blk
virtio1 device=0x0001 driver=virtio_net
virtio2 device=0x0004 driver=virtio_rng
virtio3 device=0x0013 driver=vmw_vsock_virtio_transport
virtio4 device=0x0005 driver=virtio_balloon
```

Five devices: a disk, a network card, an entropy source, a vsock channel to the host and a memory balloon. The device numbers are the virtio device IDs from the [virtio specification](https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.html) (1 network, 2 block, 4 entropy, 5 balloon, 19 vsock).

`lspci` isn't installed in the base image, so read the PCI bus from `/sys` instead:

```bash
sbx exec $id 'for d in /sys/bus/pci/devices/*; do echo "$(basename $d) $(cat $d/vendor):$(cat $d/device) class=$(cat $d/class)"; done'
```

```text
0000:00:00.0 0x8086:0x0d57 class=0x060000
0000:00:01.0 0x1af4:0x1042 class=0x018000
0000:00:02.0 0x1af4:0x1041 class=0x020000
0000:00:03.0 0x1af4:0x1044 class=0xffff00
0000:00:04.0 0x1af4:0x1053 class=0xffff00
0000:00:05.0 0x1af4:0x1045 class=0xffff00
```

That is the whole PCI bus: one host bridge (class `0x0600`) and the same five virtio devices, vendor `0x1af4` (the virtio vendor ID). In virtio-pci, a modern device's PCI ID is `0x1040` plus its virtio ID, so `0x1042` is block and `0x1053` is vsock. There is no USB bus (`/sys/bus/usb` doesn't exist), no VGA card and no sound card. A full VM on a PC machine type would list a chipset, USB controllers and display hardware here. This is the "minimal emulation" from the definition, visible as six lines.

### It boots fast because there is little to boot

```bash
sbx exec $id "systemd-analyze"
```

```text
Startup finished in 346ms (kernel) + 1.730s (userspace) = 2.077s
multi-user.target reached after 1.715s in userspace.
```

The kernel was up in 346 ms with no firmware stage before it; most of the 2 seconds is Ubuntu's userspace starting services. On our single run (2026-10-27), `sbx new` itself returned after about 19 seconds, which also covers placing the sandbox, preparing its disk and network, and waiting until it accepts commands.

### It's still a whole machine

```bash
sbx exec $id "free -m"
sbx exec $id "ls -l /dev/kvm"
```

```text
               total        used        free      shared  buff/cache   available
Mem:            3914         304        3178           0         636        3609
crw-rw---- 1 root kvm 10, 232 Oct 27 02:44 /dev/kvm
```

The guest sees its own 4 GB of memory (the `small` size) and uses about 300 MB after boot. "Micro" describes the VMM and device model, not what you can run: the guest has systemd, root via `sudo`, Docker and its own `/dev/kvm` for nested VMs. See [Docker and nested KVM inside an agent sandbox](/guides/docker-and-kvm-inside-an-agent-sandbox).

Delete the sandbox when you're done:

```bash
sbx delete $id --yes
```

## FAQ

### Is a microVM the same as a container?

No. A container is a group of processes on the host's kernel, isolated by namespaces and cgroups. A microVM is a real virtual machine with its own kernel, isolated by hardware virtualization through KVM. [Kata Containers](https://katacontainers.io/) runs containers inside lightweight VMs to combine the two.

### Is KVM a type 1 or type 2 hypervisor?

KVM is part of the Linux kernel and runs guests directly on the CPU's virtualization extensions, which is why it is often called type 1; because the same kernel also runs ordinary programs, some people call it a hybrid. The VMM, such as Firecracker or Cloud Hypervisor, is an ordinary user-space process that asks KVM to create the VM and its vCPUs.

### What makes a microVM "micro"?

The VMM and the virtual hardware, not the guest. A microVM VMM emulates very few devices, uses virtio for I/O and usually skips firmware. The guest can still be large: a Sandboxer sandbox runs full Ubuntu 24.04.

### Does AWS Lambda use microVMs?

Yes. Firecracker's README says it was built at AWS to "accelerate the speed and efficiency of services like AWS Lambda and AWS Fargate".

### Can I run a microVM on Windows or macOS?

Firecracker and Cloud Hypervisor need a Linux host with KVM, and Cloud Hypervisor can also use the Microsoft Hypervisor on Linux. On a Windows or Mac laptop, you'd run them inside a Linux VM, or use a hosted microVM such as a Sandboxer sandbox.

## Related

- [Container vs microVM for untrusted code](/guides/container-vs-microvm-for-untrusted-code)
- [Firecracker vs Cloud Hypervisor](/guides/firecracker-vs-cloud-hypervisor)
- [What is an AI agent sandbox?](/guides/what-is-an-ai-agent-sandbox)
- [Machines](/docs/machines)