Learn Firecracker - Balloon, Entropy & Resource Control

#Introduction

In episode 9 we could freeze and revive microVMs. Now the subtler challenge: how do hundreds of microVMs share one host fairly? Episode 10 covers resource control — memory via the balloon device, entropy via virtio-rng, and hard CPU/memory limits via cgroup v2.

Why is this episode important? Without resource control, a single microVM could drain all memory or monopolize the CPU, taking down its neighbors. With the balloon and cgroups, operators can specify precisely how many resources each VM may use — the foundation of the multi-tenant economics that make Firecracker viable at AWS scale.

#Balloon: Reclaiming Memory

The virtio-balloon device is Firecracker's mechanism for reclaiming memory from the guest back to the host. The concept: the host "inflates" the balloon inside the guest, pushing the guest to release unused memory pages; those pages return to the host pool and can be used by other VMs.

Configure the balloon before boot:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/balloon \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{
    "amount_mib": 128,
    "deflate_on_oom": true,
    "stats_polling_interval_s": 10
  }'

Important fields:

• amount_mib — how many MiB of memory to pull back from the guest (the balloon inflates by this amount).
• deflate_on_oom — when the guest runs low on memory (OOM), the balloon automatically deflates to give memory back — a safety net that prevents the guest from being killed.
• stats_polling_interval_s — the interval for collecting guest memory statistics.

The balloon size can be changed dynamically after boot via PATCH /balloon — inflate when a VM is idle, deflate when it needs more:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PATCH http://localhost/balloon \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{ "amount_mib": 512 }'

#Balloon Statistics: Measuring Memory Pressure

Balloon statistics give you a window into guest memory conditions from the host side. With stats_polling_interval_s active, the host can read:

curl --unix-socket /tmp/firecracker.sock http://localhost/balloon/statistics

The output is JSON containing metrics like free_memory, available_memory, pages_reclaimed — data an orchestrator can use to decide when to inflate/deflate the balloon automatically. This is the same control loop pattern as memory reclamation in modern hypervisors: monitor → decide → adjust.

Firecracker maps the balloon device via MMIO, just like the other virtio devices. That means it follows the same rules: configurable only before boot, and it runs as a standard virtio device the guest kernel recognizes.

#Entropy: Virtio-rng

A freshly spawned microVM often lacks entropy — the source of randomness for cryptography (TLS, UUIDs, keys). The host has getrandom and hardware RNGs; a guest inside a VM doesn't automatically get access to them. Without entropy, cryptographic processes in the guest can block waiting for randomness.

The solution is the virtio-rng device, enabled by default in Firecracker's configuration, which injects entropy from the host into the guest. Its configuration can be tuned through the machine config:

curl --unix-socket /tmp/firecracker.sock -i \
  -X PUT http://localhost/machine-config \
  -H 'Accept: application/json' -H 'Content-Type: application/json' \
  -d '{
    "vcpu_count": 2,
    "mem_size_mib": 1024,
    "entropy": { "rate_limiter": { "ops": { "size": 1000, "refill_time": 100 } } }
  }'

Check entropy inside the guest:

cat /proc/sys/kernel/random/entropy_avail

If the number is high and never stalls, virtio-rng is working. Note too that a rate limiter can be applied to the entropy device — preventing a single VM from draining the host's entropy source with excessive requests.

#cgroup v2: Hard CPU and Memory Limits

The balloon is persuasive (it asks the guest to release memory). cgroup limits are enforced — at the kernel level, without guest cooperation. With cgroup v2, each microVM is placed in its own cgroup:

mkdir -p /sys/fs/cgroup/fc/<id>
echo 1024 > /sys/fs/cgroup/fc/<id>/memory.max
echo 500000 > /sys/fs/cgroup/fc/<id>/cpu.max

Reading these values:

• memory.max — maximum memory (bytes) for the group. If exceeded, the kernel reclaims; if it can't, OOM-kill happens inside the group.
• cpu.max — in quota period format (e.g. 500000 100000 = 500 ms per 100 ms period = 5 vCPUs).
• cpuset.cpus — choose which CPUs can be used, helping isolation and NUMA.

Then place the Firecracker process into the cgroup:

echo <firecracker-pid> > /sys/fs/cgroup/fc/<id>/cgroup.procs

The jailer already creates a base cgroup for each VM; with cgroup v2, operators extend it with explicit limits. The combination of balloon + cgroup is the complete pattern:

• cgroup enforces the maximum (a VM never passes its limit).
• balloon manages distribution (memory flows to the VMs that need it while others are idle).

The two work at different layers and complement each other.

#Per-Device Caps and the Rate Limiter

Besides cgroups, every I/O device has its own limits via the rate limiter (covered in episode 5). The complete resource control map:

• CPU: cgroup cpu.max + the vCPU choice in the machine config.
• Memory: cgroup memory.max + balloon amount_mib.
• Network I/O: bandwidth + ops rate limiters on the network interface.
• Block I/O: bandwidth + ops rate limiters on the drive.
• Entropy: an ops rate limiter on the entropy device.

With this map, operators can give measurable service promises per VM — and enforce them across several layers at once.

#Common Pitfalls

• Balloon without a guest driver: the balloon isn't effective if the guest kernel doesn't support virtio-balloon.
• deflate_on_oom false: risk of the guest being killed under memory pressure; enable it unless there's a strong reason not to.
• cgroup limit smaller than the VM's memory: the host kernel will OOM-kill the Firecracker process — always keep memory.max > mem_size_mib + overhead.
• Forgetting the entropy rate limiter: one VM with heavy entropy requests can drain the host.
• Balloon statistics without an interval: stats_polling_interval_s must be set for statistics to be collected.

#Closing

The key takeaways:

• The balloon reclaims memory from the guest with the virtio driver's cooperation.
• deflate_on_oom prevents OOM in the guest when the balloon is too aggressive.
• Balloon statistics provide data for the memory management control loop.
• Virtio-rng provides entropy; check with entropy_avail.
• cgroup v2 enforces hard CPU (cpu.max) and memory (memory.max) limits.
• The rate limiter covers the I/O side; balloon + cgroup = persuasion + enforcement.

In the next episode 11 we'll bridge Firecracker with the container world: Container Integration — firecracker-containerd — the containerd runtime that runs each container inside its own Firecracker microVM, understanding the runtime and overlay snapshotter components, and the pull → unpack → run flow of running a container in a microVM with bridge networking.