FastVM puts an idle virtual machine to sleep and lets an incoming packet wake it

The virtual machine is asleep when the packet arrives. FastVM’s proposed answer is to wake it with that packet already waiting in the guest’s receive path. The incoming frame both triggers the wakeup and remains available for the restored guest to handle, so the request survives the interruption.

The repository describes a single-host runtime built around Firecracker and KVM. Its lifecycle moves an idle sandbox through pause into a dormant state whose guest memory is backed by a file. An incoming network frame can start the return trip to useful work. The important trick is keeping the request that caused the wakeup in the path that will answer it.

The project distinguishes pause from dormant. Pause leaves guest memory resident; dormant hands it to a memory file while keeping the virtual-machine monitor paused. That means this is a particular kind of sleep, with a monitor still present. Deep sleep that exits the monitor appears on the not-yet-wired list. That distinction matters when estimating what the dormant guest leaves running on the host, before counting any hoped-for savings in memory.

The README reports a working Linux bridge data plane and end-to-end KVM tests by its maker. It also lists an eBPF switch as implemented and tested separately, but not connected to the daemon. A reader looking at the switch configuration could otherwise come away believing a more ambitious network path is already in service. The limitations section saves a detour.

Requirements put the experiment firmly on the infrastructure side: Linux x86_64, accessible KVM, Firecracker, and privileges for the host’s TAP, bridge and network translation setup. This is a machine that gets to adjust networking on the host. It deserves a test environment with that authority accounted for, rather than a casual paste into whatever server happens to be open.

The appealing workload is something that spends meaningful time idle but needs to respond when a request returns. Whether sleeping helps depends on what remains resident, the cost of saving and restoring memory, and how often outside traffic wakes the guest. Traffic that keeps waking the guest could eat into its useful idle time, so the request pattern belongs in the same measurement as memory and disk use. Those are measurements for the actual application, rather than savings established by a lifecycle diagram.

The maker’s tests are useful evidence of an implemented path, but they aren’t a performance result for your deployment. A cold boot, a wake from resident pause and a wake from disk-backed memory answer different latency questions. Reporting one as though it described all three would make the product name do considerably too much work.

There is also a distribution question before adoption. Source is publicly readable, but the repository doesn’t state a license. Seeing implementation details helps an evaluation; it doesn’t supply the permissions normally conveyed by a license. That is something to resolve before building an organizational dependency around it.

As an early experiment, FastVM is interesting because the handoff includes the request that woke the machine. The remaining operational question is whether your own workload can spend enough time asleep to justify the wakeups, disk traffic and host machinery around it.

Packet delivered. Nap interrupted.