How long does a usable environment take to start?¶

Conclusions¶

With prepared environments, pVisor host and staged produce first output in 12.72 ms and 25.13 ms respectively. With Linux/KVM and 2 vCPU / 128 MiB, pVisor VM takes 100.91 ms, ahead of Firecracker (285.04 ms), QEMU (702.98 ms) and microvm (321.56 ms) using the full Fedora kernel.

Motivation¶

Disposable environments repeatedly pay for the first command. Choosing host, staged, containers or VMs requires knowing their startup waits and the cost of the isolation you need. Short tasks also pay for exit and tools.

Experiment design¶

Linux x86_64 / KVM, AMD Ryzen 7 9700X, Fedora host. The controls are native, pVisor host, pVisor staged, pVisor VM, rootless Docker / overlay2, Firecracker PCI, QEMU q35 and QEMU microvm. Launch trees are pinned to CPUs 0,1; every VM has 2 vCPU / 128 MiB. Processes and containers have no memory limit.

Firecracker, QEMU and microvm use the full Fedora distribution kernel, Linux 7.2.8-200.fc44.x86_64. pVisor's virtualization is based on libkrun and uses its companion libkrunfw project's customized kernel, Linux 6.12.109.

Prepared userspace environments run the same /bin/sh output probe. Each execution uses a fresh environment and private workspace; every VM boots afresh, without snapshots or environment pools. Warm page caches, three warmups and sixty measured samples per backend, with randomized interleaving within each measurement group. Environment preparation and input copying are outside startup timing. Kernel, device and storage paths differ, so results cover each complete startup configuration. This probe does not cover full distribution boot, cold images, Agent CLI initialization, concurrent capacity or snapshot restoration.

Ready ends at the checked first shell marker. Exit includes execution and teardown, requiring correct output and a normal zero exit. Firecracker is stopped under control after checking markers and results and confirming no panic; only Ready is reported. Failures, panic, mismatched output or changed artifacts are excluded from timing distributions; valid slow samples are retained.

Data and analysis¶

Startup and exit times¶

Unit ms, N=60 per backend, zero measured failures. Process/container and VM measurements were collected separately, with each row retaining its own statistics; all four VM controls were randomly interleaved within one group. P95 describes the distribution rather than guaranteeing stable tail latency.

Host and staged wait tens of milliseconds, making them suitable for frequently launched short commands. VMs also initialize a kernel and devices; choose isolation with complete-task timing in mind. Blank Firecracker Exit cells mean normal shutdown is unmeasured.

Differences are differences between the two medians, with 95% intervals from 5,000 bootstrap resamples of matching rounds. All three intervals exclude zero, supporting faster pVisor VM startup for these configurations. Dedicated firmware and simplified initialization provide a shorter startup path; this comparison cannot separately quantify kernel, filesystem and VMM contributions.

For cold-image client waiting and content downloads, see the separate on-demand image startup experiment. Image-service preparation is recorded separately, and its samples are not pooled with these prepared-environment results.

Downloads and reproduction¶

Startup statistics · VM differences and 95% intervals · VM source and artifact provenance · Method · Reproduction manual. Binaries, complete inputs and raw logs stay in local ignored .data/; CSVs retain statistical sources and sample counts, and provenance records retain CPU/RAM configuration and report/artifact digests.