What makes the firecracker microvm "micro" vs something like qemu?

Question

From https://firecracker-microvm.github.io/:

Firecracker is an alternative to QEMU that is purpose-built for running serverless functions and containers safely and efficiently, and nothing more. Firecracker is written in Rust, provides a minimal required device model to the guest operating system while excluding non-essential functionality (only 5 emulated devices are available: virtio-net, virtio-block, virtio-vsock, serial console, and a minimal keyboard controller used only to stop the microVM). This, along with a streamlined kernel loading process enables a < 125 ms startup time and a < 5 MiB memory footprint. The Firecracker process also provides a RESTful control API, handles resource rate limiting for microVMs, and provides a microVM metadata service to enable the sharing of configuration data between the host and guest.

So what is the main thing that makes qemu slower—primarily the device emulation?

And that startup time of 125ms + 5MB is in contrast to...what?

Answer 1

Yes, firecracker boots faster and is lighter than QEMU, the numbers vary (from little to 10x) with the kernel used and options (drivers, devices) given. There is an older paper on that here: https://dreadl0ck.net/papers/Firebench.pdf – which finds firecracker faster but not impressively so:

In our experiments the mean kernel boot time of Firecracker microVM is 800ms in the sequential experiments, and 1000ms in the concurrent scenario. QEMU boots the Linux kernel 18% slower on average. […] It is important to note that the network stack setup during takes additional time, without initialising the network stack the machine is able to boot in 150ms-200ms. The reduced boot time of Firecracker can be explained by the fact that Firecracker only emulates five devices: virtio-net, virtio-block, virtio-vsock, serial console, and a minimal keyboard controller used only to stop the microVM.

But I would evaluate this from another perspective: firecracker is purposefully minimal to present less possibility for configuration mishaps and importantly minimal attack surface (it's usually used to run untrusted workloads). Also full control by ReST-API makes it easy to orchestrate.