VM startup: technical analysis and experiment records¶

Historical cohorts retain their pinned sources, artifacts and timing scope. See the benchmark registry for active experiments and preparation status.

Note: "local original records" and paths such as docs/src/assets/benchmarks/.data/ refer to local measurement archives that are not published with the repository or the site; they are kept for batch provenance only.

Linux: startup and exit fixes retest, 2026-10-11¶

Exit cleanup has a measured benefit, but startup regressions are not fully resolved. Against the cf8bfa5 GNU artifact, host Ready improves by about 9.11 ms and Exit by 75.00 ms. VM Exit improves by about 48.26 ms, with no detected Ready improvement. New staged Ready has two separated clusters and cannot be declared restored.

Motivation and experiment design¶

This experiment checks fixes for repeated binary reads/hashes, repeated process-tree cleanup and fixed waits, together with the new filesystem execution model. The three arms are the historical cfe36981 GNU release/gateway artifact, the cf8bfa5fe8ad3438a096a2293bcc411176d388c8 GNU release/gateway artifact, and current frozen build2. All VMs use the same dynamic firmware, without mixing GNU and musl. Candidate SHA256 is 87ebb0658f2df6a84f9e4eca29c8d3d8bc01923817f04432780272c8b1b30309. Other source changes intervene between historical and current versions, so differences cannot be attributed solely to hashing or cleanup.

B-STARTUP-REVISION-ENG, Linux/KVM/FUSE: 3 warmups and 60 shuffled paired rounds per backend/version, seed 20261011. Host, staged and VM run sequentially, without overlapping filesystem sampling. The whole parent uses CPUs 0,1, a two-core quota, 16 GiB and zero swap; VMs have 2 vCPUs and 128 MiB. Each arm owns a private user/mount/PID namespace, pivot_root and warmed Host listener. Input/namespace preparation and initial service startup are outside timing. The original startup workload measures Popen to exact Ready and normal zero exit, checking output, Run Bundle, isolation and complete before/after input inventories. Formal timing uses the original Python perf_counter_ns observer without profiling, not hyperfine.

Data and analysis¶

All 540 formal runs and 27 warmups passed, with unchanged artifact hashes and no external build/test interference detected. Intervals use 5,000 paired-round bootstrap resamples. All slow valid samples are retained; separated clusters have no whole-distribution median ranking, and no P99 is reported. Against cf8bfa5:

• Host Ready is 29.14 → 20.03 ms: -9.11 ms, CI95 [-9.51, -8.72]. Exit is 99.16 → 24.16 ms: -75.00 ms, CI [-75.24, -74.59]. Against historical cfe36981, Ready still adds 6.82 ms, CI [6.16, 7.27], and Exit 0.25 ms, CI [0.02, 0.63]. The major exit regression is removed, but not every metric is restored.
• Staged baseline Ready is 41.23 ms. Candidate Ready has 19/41 samples in two clusters, with medians 32.17/121.95 ms; no overall improvement percentage is assigned. Exit is 118.41 → 118.67 ms, with difference interval [-31.54, 16.60] crossing zero. Historical-control Exit also has separated clusters: 53/7 samples at 34.12/74.43 ms.
• VM Ready is 119.41 → 115.25 ms: -4.16 ms, CI [-7.08, 0.77] crossing zero. Exit is 218.71 → 170.45 ms: -48.26 ms, CI [-67.43, -33.36]. Historical cfe36981 Ready/Exit in this cohort are 174.06/211.83 ms, slower than current. The versions differ in several ways, so this does not isolate a single optimization.

Overall performance acceptance still fails: staged startup is variable, and the same-artifact filesystem retest shows remaining VM write/tool regressions. These require separate diagnosis; host exit gains cannot stand in for other backends or internal task performance.

Full statistics, distributions, paired intervals, artifact and provenance records remain in the local batch or archive. Raw samples, per-trial stdout/timing, Run Bundles, inputs and build receipts are under benchmark/startup/.data/concurrency-retest2-20261011/. These engineering version comparisons do not overwrite historical cross-runtime user tables or cover cold caches, concurrent workloads, macOS or initial service startup. Polling every 0.5 s may miss brief, inaccessible or unrecognized interference.

Capability checks for current generic and trimmed kernels¶

The trimmed configuration passes these staged-workspace, development-tool, IPv4 HTTP and execution-snapshot restoration checks. Tests use the current CLI and two firmware variants rebuilt from identical Linux 6.12.109 sources, patches and compact packaging implementation. Complete digests verify all 79 frozen source inputs and both actual build input trees before and after; the CLI's 1,063 product source/dependency files match the current worktree. Measured on 2026-10-06, Linux/KVM, host CPUs 0,1 and 2 configured vCPUs. Tool preflights sample resources; these capability checks do not provide formal timings.

The table gives passes/attempts per configuration: 60 independent VM executions, zero failures. Shell, seven-tool and fixed-repair checks run twice per variant; every network/restore condition runs three times, with seeded randomized alternating order.

All twelve tool-preflight lower inventories remain unchanged. Four write checks produce 1,024 files totaling 64 MiB, with every byte independently audited. The frozen harness checks child tests, and retained repaired files are independently inspected afterward. The HTTP origin runs on the same host; allowed requests provide positive controls and deny conditions test direct sockets. No public-network or model requests are used. All 24 restored execution tokens are unique; original stdout, suspended state, restore results and OOM events are independently audited. Shared tool inputs and memory fixtures remain identical before and after.

Shell uses 128 MiB guest RAM, tools 16 GiB and networking 1 GiB, under an existing private 16 GiB parent budget. Restore uses 256 MiB guest RAM in a fresh 2 GiB, zero-swap, 200% CPU service per execution. Tool preflights sample processes; network checks verify the coordinator/parent budget, while restore checks verify service limits and sample memory. CPU placement uses affinity; complete placement over every short thread lifetime is unproven, and unknown observations remain explicit. These checks do not establish rankings or capacity under uniform strict resource enforcement.

Actual built kernel options¶

Both configurations enable SMP, KVM guest, CPU mitigations, seccomp/filter, namespaces, virtio-mmio, virtio-fs, virtio-net and IPv4. Trimming disables PCI, ACPI, guest security/SELinux and audit. Both still enable CONFIG_BLOCK, so device trimming cannot be described as removing all block infrastructure. Configuration differences do not establish identical hardening. Validation covers the listed HTTP and private-memory restore workloads, without a complete device, TLS/DNS/UDP/IPv6, escape-resistance or SDK-state restoration guarantee. It establishes no startup, physical-memory or density gain.

Capability and actual-configuration CSVs remain in the local batch or archive, retaining cohort timestamps, sample counts and digest associations. The two independent raw reports, individual outputs, snapshots, input manifests and build/audit receipts stay in local .data/. See the kernel configuration experiment manual. Startup and complete-task gains need separate formal paired timing with the current CLI; capability passes or file sizes cannot establish them.

1. Conclusions¶

A new pVisor VM returns its first command output in about 84 ms on macOS / Apple M4 and 110 ms on Linux / Ryzen 7 9700X: roughly 0.1 seconds. On the same Linux host, Firecracker starts complete Ubuntu in 5.64 seconds after provisioning or 9.25 seconds on first boot. pVisor uses directories without an OS image. Configurations differ between batches; all evidence is retained separately.

2. Motivation¶

Agent executors may repeatedly create isolated environments. Startup waiting affects the first command's response time and the total cost of short tasks. This work therefore measures the complete path from launching the CLI to executing a guest workload, rather than only one interval in kernel initialization logs.

Earlier investigations covered Run record persistence, runner parameter transport, early random initialization and firmware trimming. A consistent protocol is needed to establish current performance and distinguish validated gains from experiments without stable benefits. This measurement addresses three questions:

• How long does a new VM take from CLI launch to workload readiness, and how long does exit and finalization take?
• With the same CLI, how do official and trimmed firmware differ in median and tail latency?
• How much time goes into host preparation, process loading, VMM construction and guest execution, and where should optimization focus next?

Optimization must preserve isolation, durable Run records and attestation semantics. Successful execution samples must support performance claims; shorter kernel logs, smaller files or less code cannot independently replace end-to-end measurements.

3. Experimental design¶

Timing boundaries and workload¶

Measurement starts when pVisor launches and ends when a new VM executes its first shell command and returns output, labeled Ready in the tables. It covers host preparation, VM startup and command execution: the startup wait after a user issues a command.

Exit runs from the same starting point until normal runtime exit, including result persistence and shutdown. Every trial creates a fresh VM with warm host caches. pVisor uses directories; reference image download and creation occur before timing. Complete Ubuntu additionally requires distribution services to be ready, with a separate new batch.

Environment and configuration¶

Hardware, guest filesystems, firmware and CLI artifacts are recorded separately. Both datasets share timing boundaries and describe startup in their respective environments; cross-platform figures do not isolate operating-system or virtualization-backend speed.

Sampling, validation and statistics¶

Cases are warmed up and randomly ordered per round, with separate Ready/Exit distributions and successful long tails retained. macOS and the early Linux main matrices use N=100; the new deployment comparison uses N=30. Stage diagnostics are separate. Each table states N, excluding warmups.

Every pVisor sample requires completed records and a zero exit code; VM samples also verify actual virtual_machine isolation. Failures or missing readiness output never enter successful distributions. Historical main matrices stop on failure; the new deployment comparison records failures and continues other cases. Percentiles describe the batch rather than guarantee long-term tails or performance on other machines.

Routine startup diagnostics¶

Startup logs help identify which phase accounts for the wait. They are enabled by default; set PVISOR_STARTUP_TIMING=0 to disable them. This article retains both the original matrix without logs and the latest remeasurement with logs enabled. Use results from the same batch when comparing variants.

4. Experimental data and analysis¶

Measured median startup for new VMs is on the order of 0.1–0.2 seconds. macOS data includes firmware comparisons, phase diagnostics and controlled optimization remeasurements; Linux data includes three memory shapes and host controls. Each dataset's complete results and analysis follow separately.

macOS / HVF¶

The latest Apple M4 remeasurement has median readiness 84.35 ms and P95 112.14 ms. Controlled remeasurement records those results; the full matrix and phase accounting below come from earlier independent batches and remain separate.

Full matrix: end-to-end results without diagnostic logging¶

Figure 1: Readiness across VM shapes. Panels use different x-axis ranges. P99 retains tail samples; a better median does not mean every launch improves equally.

All values are milliseconds, N=100 per row. direct is native shell, host is the pVisor host executor, and VM names encode firmware, vCPU count and MiB.

With 100 samples, P99 is close to the observed maximum and cannot guarantee long-term tail latency. Background load, power, APFS persistence and scheduling affect later batches. The earlier roughly 84 ms observation came from another batch; it is not a fixed performance constant.

The batch also contains substantial tails: trimmed 4 vCPU / 128 MiB has 2/100 trials above 200 ms, maximum 412.91 ms; official 2 vCPU / 128 MiB has 3/100, maximum 389.00 ms. Rounds 15 and 68 each contain multiple slow cases. Main samples lack fine-grained diagnostics, so persistence, scheduling or other host activity cannot be assigned as the cause. All successful samples remain included; outliers were not removed to improve P99.

Paired firmware improvement¶

Median paired savings need not equal the difference between group medians. More vCPUs or RAM do not necessarily start faster. This matrix uses no snapshots, resident VM pool or memory-sharing scan.

Where startup time goes¶

Diagnostics identify host preparation and guest startup through output arrival as the two main costs, each around 30 ms; VMM construction takes about 3 ms. Further reductions should focus on Run records and filesystem preparation, and on the guest startup path.

Figure 2: Phases follow startup order; horizontal position shows cumulative elapsed time. Diagnostic means sum to 87.05 ms; the table also lists P50. The guest phase includes initialization, workload execution and output arrival.

These independent diagnostics use trimmed firmware, 2 vCPU / 128 MiB and N=20. Diagnostic Ready P50 is 87.67 ms. Subtracting it from the main batch does not estimate logging overhead.

Nested preparation spans follow. Storage contains record and overlay work; do not add all three.

Durable records and overlay preparation dominate parent preparation. Runner preparation also includes device configuration and attestation. JSON parsing or one virtio-fs log line cannot explain the whole guest interval.

Validated and retained optimizations¶

Figure 3: Independent historical comparisons validate persistence and boot entropy changes. Each uses 50 pairs, with different shapes and batches; they are not a continuous optimization timeline and gains cannot be added.

Remove duplicate persistence while preserving Run semantics¶

Non-Gateway startup combines initial RunRecord writes. Unchanged indexes reuse their inode and contents while retaining required file and directory synchronization; invalid indexes, permissions and moved paths are repaired. Runner specs use private temporary IPC files held by the parent, without long-lived-record fsync requirements.

An earlier 50-pair, no-log experiment at 2 vCPU / 2 GiB with identical trimmed firmware reduced Ready P50 from 163.522 to 136.217 ms. Median paired savings were 24.507 ms, with 48/50 pairs faster. Parent main-to-spawn P50 fell from 54.804 to 34.675 ms. This validates persistence changes within that batch; do not concatenate it with today's numbers as a single experimental curve.

Supply fresh boot entropy¶

The aarch64 FDT supplies a fresh 32-byte rng-seed for every new VM from the host OS random source. RNG failure stops boot instead of falling back to a fixed seed. Linux obtains early entropy without removing guest DRBG or entropy health checks.

An earlier 50-pair, no-log experiment at 2 vCPU / 128 MiB reduced Ready P50 from 129.270 to 82.268 ms. Paired savings were 47.614 ms, 95% CI [46.590, 48.750], with 50/50 pairs faster. The diagnostic CPU_ON interval fell from about 49.849 to 4.080 ms. That interval includes its surrounding startup path, not 50 ms of pure PSCI execution.

Trim firmware to actual VM and Agent requirements¶

Unused GPU/display/input hardware, rare filesystems and crypto algorithms, debugging exports and unnecessary memory/power capabilities were removed. Required virtio, virtio-fs, console, networking and crypto remain. Algorithm self-tests and Jitterentropy health checks are separate mechanisms; security checks were not indiscriminately disabled.

Today's paired data validates the combined trimmed artifact, not an exact contribution from each removed driver. Smaller kernel code can reduce mapping, initialization and cache costs, but file size alone does not determine boot time. The customized libkrunfw configuration remains the authority for enabled capabilities.

Remove experiments without stable benefits¶

The compressed init argv transport was removed; guest initialization still reads bounded JSON. The kernel random-capability cache patch remains experimental because additional benefits after FDT seeding were unstable. A 20-pair cleanup comparison showed no stable regression. Detailed per-exit/MMIO and virtio-fs instrumentation was removed; lightweight, default-off host checkpoints remained at that point; this mechanism now provides the routine diagnostics described above.

Controlled remeasurement of both P0 changes¶

The baseline is fixed commit 52e77c60d6352960a4d2ab4ef8661f3d5b1b2797. Changes are applied sequentially, excluding concurrent HVF/VMM working-tree edits. All release artifacts use one isolated source and target directory: baseline is unchanged, attestation removes temporary receipt synchronization, and both additionally deduplicates directory barriers. Firmware and prepared rootfs remain identical; routine checkpoints are enabled throughout (1 is equivalent to default behavior). Official firmware was not remeasured; its earlier numbers are not a same-round control for these results.

Round one retains complete receipt writes, normal-exit validation and failed-entry truncation, removing only two sync_data() calls. Round two creates the full directory tree before syncing the first new directory's parent and each new directory once. N new levels require N+1 directory barriers instead of 2N. Existing-directory behavior and sync-error propagation retain their contracts; RunRecord and index publication remain synchronous atomic operations.

At 2 vCPU, each artifact has 100 formal samples and 5 warmups at 128 and 2048 MiB: 600 formal samples and 30 warmups. All six cases are randomized each round. Values are milliseconds; Ready still runs from before process creation to workload stdout marker, while Exit is measured separately. See the Local raw record docs/src/assets/benchmarks/.data/startup-p0-20261003.tsv for samples and hashes.

Round one has positive end-to-end paired intervals at both memory sizes. Its attestation span falls from about 4.03 to 0.04 ms; all 100 pairs at 128 MiB improve that span. Round two's independent end-to-end intervals still cross zero, so an additional stable millisecond gain is not established; redundant directory calls are demonstrably reduced. The combined changes improve the median in this batch, but 128 MiB Ready P95 changes from 107.99 to 112.14 ms, so tail latency does not improve universally.

An earlier batch used 50 samples per case, with 1-minute host load average falling from 18.38 to 8.66 and all end-to-end intervals crossing zero. Its Local raw record docs/src/assets/benchmarks/.data/startup-p0-20261003-first.tsv remains archived and is not pooled with this batch. The second batch's load average is 5.67 → 6.87: lower, but not a fully isolated idle host. All successful tail samples remain included.

Savings are median same-round differences, with 5,000 bootstrap resamples. Median gains from the two rounds cannot be added. Nested-span medians do not sum to total latency either. Intervals crossing zero do not establish stable improvement; exit tails and readiness tails remain separate observations.

Checks cover four sync targets for three new directory levels, no additional barriers for existing directories, and immediate sync-error propagation. All artifacts also pass real-VM success, nonzero guest exit and deadline checks: the first two retain enforcement evidence; deadlines leave it unknown. Temporary receipts are not recovery state. These checks validate runtime semantics, not actual power-loss behavior.

Next optimization boundaries¶

Temporary attestation synchronization and duplicate barriers within directory creation are addressed by the P0 experiments above. Next investigate barriers across RunRecord/index publication and preparation steps, then process loading and PID1 work, preserving failure, cancellation and attestation semantics.

RunRecord is authoritative state before execution. Required persistence cannot become an unawaited background task. Merge redundant barriers and parallelize independent work where safe, then validate with paired measurements and failure/recovery checks.

Linux / KVM¶

Image-free pVisor and complete Ubuntu: deployment waiting¶

A fresh short-task VM becomes usable in about 0.11 seconds; complete Ubuntu on Firecracker takes 5.64–9.25 seconds to boot and execute a command. Ubuntu comes from the latest official cloud VM release, pinned to 26.04.1 LTS / 20260927. Its stock 7.0.0-34-generic kernel, initrd, modules and services are retained. The command runs after systemd multi-user, networking, cloud-init and the SSH socket are active. pVisor uses --rootfs host, its embedded kernel, and installed host tools without preparing an OS image.

Linux / KVM, 2 vCPU / 2 GiB, the same two-core host budget, 30 samples for each of the first five rows and 10 for each QEMU follow-up row, all with 3 warmups; the batches pass 150/150 and 20/20 formal startup trials respectively. Every trial creates a fresh VM without a RAM snapshot or resident pool, with warm host disk caches. Prepared Ubuntu uses a disk template with installed tools and completed initial cloud-init. First boot uses an uninitialized complete Ubuntu template with NoCloud networking and the measurement service, without the complete Agent toolset. First boot does not include downloading the image.

QEMU boots the same complete Ubuntu, rather than the historical trimmed kernel. q35 and microvm share Firecracker's stock kernel, initrd, tools and initialized disk template. A minimal device model does not remove seconds of distribution boot in this configuration. These are independent same-host cohorts; QEMU has N=10, background host load remains, and outliers are retained. Similar medians do not support a precise VMM ranking. QEMU first cloud-init boot is unmeasured.

Local raw record docs/src/assets/benchmarks/.data/full-ubuntu-qemu-20261004/samples.csv · QEMU protocol

Selection meaning: Creating environments for one or two commands benefits from avoiding seconds of OS boot. Complete Ubuntu provides distribution services and an independent Ubuntu environment at that startup cost. These are deployment paths with different kernels, initialization and storage; the table does not establish a roughly 50-times VMM advantage for libkrun. For longer jobs, compare task and internal tool time, where boot cost is amortized.

Exit includes normal shutdown: pVisor P50 is 174 ms, Firecracker/Ubuntu about 9.23 / 12.86 seconds. Firecracker/Ubuntu uses default MMIO devices and the stock initrd, with zero VMM exit after guest reboot. Every trial retains full OS proof with no failed units. Workspace copying or private disk cloning is recorded as prepare_ms, with medians around 37 / 29 ms outside Ready. The chart uses a logarithmic axis, bars P50 and ticks P95. With N=30, P99 is near the maximum and describes this batch only.

Local raw record docs/src/assets/benchmarks/.data/full-ubuntu-20261004/samples.csv · Local raw record docs/src/assets/benchmarks/.data/full-ubuntu-20261004/summary.tsv · Method and reproduction · Local raw record docs/src/assets/benchmarks/.data/full-ubuntu-20261004/ubuntu-ready-mmio-20261004/evidence.tar.gz

New VM startup results¶

At 2 vCPU / 128 MiB, median readiness is 172.69 ms and P95 is 180.37 ms. Median readiness is approximately 175 ms at 256 MiB and 220 ms at 2 GiB. This workload only prints one line; additional configured RAM does not reduce startup waiting.

Values below are milliseconds, with 100 measured samples per row. Ready ends at the first command output; Exit includes finalization. Host controls run in the same rounds, and all VM samples pass isolation checks.

In this batch, new VMs become ready in about 0.2 seconds, with exit completion around 0.23–0.28 seconds. Evaluate those boundaries separately. These are fresh VM launches and do not establish snapshot restoration time. Linux has no detailed startup phase accounting in this batch, so macOS phase proportions cannot be applied to it.

Trimmed kernel and direct init: historical Docker / Firecracker / QEMU controls¶

These Firecracker/QEMU controls use a trimmed kernel and static init, skipping Ubuntu system-service boot. The 73.74 ms value belongs to that minimal path; see the complete Ubuntu deployment comparison above. pVisor in this historical batch uses a prepared tool directory shared through virtio-fs, without an OS image.

With the same two-core host execution budget and prepared environment, pVisor VM Ready P50 is 86.29 ms, close to Docker 90.12 ms and QEMU microvm 88.10 ms; Firecracker measures 73.74 ms. This locates its hundred-millisecond scale near mature microVM paths, without claiming to beat all of them.

Bars show P50 and lines P95, not confidence intervals. N=30, 3 warmups, randomized backend order per round. VMs use 128 MiB/2 vCPU; every runtime is bound to physical host cores 0 and 1, including the Docker daemon and in-container tools. The environment already contains Python/Node/Rust/Git/Claude/Codex; the workspace has 2,048 files and a 64 MiB input. Preparation and cloning are measured separately.

QEMU q35's 218 ms does not establish QEMU's minimum startup cost: microvm with optional legacy devices disabled measures 88 ms. Both are retained. Firecracker and QEMU share a trimmed Linux 6.12.109 kernel and ext4; pVisor uses its own embedded firmware and staged virtio-fs. These are complete command paths, so their differences cannot all be attributed to the VMM.

First output does not establish that an Agent can complete a task. Seven-tool version checking takes 1.40 seconds in pVisor VM. See the complete tool environment for repair/test timing and CLI compatibility. The preceding 172.69 ms GNU/libkrunfw 5.5.0 batch remains historical evidence. This batch uses a new pinned static artifact; it is not a controlled single-configuration optimization experiment.

Configuration and reproduction · Local raw record docs/src/assets/benchmarks/.data/reference-env-20261004/samples.csv · Local raw record docs/src/assets/benchmarks/.data/reference-env-20261004/summary.tsv · Local raw record docs/src/assets/benchmarks/.data/reference-env-20261004/evidence.tar.gz · Local raw record docs/src/assets/benchmarks/.data/reference-env-20261004/compatibility.tsv

Full-exit follow-up: cleanup is separate from Ready¶

Same configuration, a separate 30 samples per backend and 3 warmups. A dedicated process waiter records exit rather than the main batch's polling; Ready percentiles remain separate. pVisor VM returns first output in about 88 ms and completes CLI exit in about 153 ms. Environment availability and completed recording/cleanup are separate budgets.

Local raw record docs/src/assets/benchmarks/.data/reference-env-20261004/followups/reference-startup-exit-20261004/report.tsv · Local raw record docs/src/assets/benchmarks/.data/reference-env-20261004/followups/reference-startup-exit-20261004/samples.csv · Local raw record docs/src/assets/benchmarks/.data/reference-env-20261004/followups/reference-startup-exit-20261004/evidence.tar.gz

5. Reproduction and raw data¶

macOS / HVF¶

Prepare the release CLI, Alpine rootfs and both firmware directories, then run:

python3 benchmark/pvisor/vm_ready.py \
  --binary target/release/pvisor \
  --rootfs target/guest-init-benchmark/rootfs \
  --official target/firmware-official-compare-20261003/official \
  --trimmed target/firmware-official-compare-20261003/trimmed \
  --output target/vm-startup-new \
  --samples 100 --warmups 5 --profile-samples 20

The output directory must not exist. The harness uses the Python standard library and existing percentile/Bundle validation helpers. Main and diagnostic batches are separate, warmups are excluded, and outputs include results.json, incrementally flushed samples.jsonl, input hashes and per-trial stdout/stderr. Its schema is pvisor-vm-readiness/v1; do not mix it with startup.py command-completion measurements.

Local logs are in target/vm-startup-20261003/; the formal JSON report and previously public data files remain in the local archive described above. Historical persistence, entropy and firmware experiments remain under review_project/03-modules/. The older C/Rust guest-init runner comparison remains in benchmark/pvisor/README.md; it excludes full CLI preparation and is not directly comparable with this table.

The measured harness snapshot is retained in review_project/06-evidence/vm-startup-20261003/; the reusable harness subsequently added explicit pipe closure and PVISOR_STARTUP_TIMING=0 for uninstrumented samples; the snapshot preserves the measured implementation.

Linux / KVM¶

Use a prepared guest root and firmware directory with a new output directory. The script reuses first-output timing and run validation, copying the CLI and firmware to pin artifact identity.

python3 benchmark/pvisor/linux_vm_ready.py \
  --binary target/release/pvisor \
  --rootfs / \
  --firmware /path/to/libkrunfw-5.5.0-directory \
  --output target/vm-startup-linux-new \
  --samples 100 --warmups 5

Local raw record docs/src/assets/benchmarks/.data/startup-linux-20261003.tsv. Per-trial stdout/stderr, warmup logs and fixed binaries remain in local target/local-vm-validation-20261003/startup-linux-100/. Changing artifacts or rootfs requires a new measurement batch with earlier records retained.

6. Unmeasured scenarios¶

Docker, Firecracker, QEMU and controlled Agent tool loops now have same-host measurements; full Ubuntu first boot and part of preparation are reported separately. a3s, real model inference, large projects, public dependency downloads, cold disk caches, TUI, Gateway, concurrent density and application health checks still require separate matrices.