fix(minvmd): resource-surface hardening from post-merge review of #775 - #793

Summary

Follow-up to #775: fixes the four confirmed findings from CodeRabbit's post-merge review of the minvmd resource surface, plus one adjacent bug the new tests exposed. Each section below states the failure as state + action → observed wrong outcome.

1. status could report resources the VM did not boot with

Failure state: A VM is booting (the ~30–60 s window between VMM-child spawn and the guest's READY marker). A user runs minvmd config set --ram-mib 8192 inside that window. → The child boots the VM with the old RAM value, but the parent re-resolves the config after READY and records the new value as State.booted_ram_mib; minvmd status then reports a RAM size the running VM does not have, silencing or fabricating any reasoning built on the booted values (R2.6).

Also: the child resolved vcpus and ram_mib as two separate config.toml reads — a config set between them boots a VM with vcpus from one config version and RAM from another.

Fix: the parent resolves the pair once, pre-spawn, hands it to the child via MINVMD_BOOTED_VCPUS/MINVMD_BOOTED_RAM_MIB, and persists that same snapshot at the Running transition. The child boots from the snapshot (local resolution only as a mixed-version fallback). Both spawn sites (run, boot) pass it.

2. A malformed config.toml broke the one command that could diagnose it

Failure state: config.toml contains invalid TOML (hand edit, partial write). → Boot silently falls back to defaults, but minvmd config show — the command a user would run to see what boot will use — exits with an error instead. Additionally, run_show's three independent config reads could label values with sources from a different file version under a concurrent config set.

Fix: config show now uses the same single-read resolution pass as boot (resolve_resources()): one snapshot supplies values and source labels, and a malformed file reports the same default fallback boot would use (with a warning on stderr).

3. Hand-edited invalid values rode straight into the VMM

Failure state: config.toml contains vcpus = 0 or ram_mib = 64 (values config set rejects — only the write path validated). → Boot resolution hands a 0-vcpu VmConfig to libkrun, or boots a guest with too little RAM to reach userspace, which then fails as an opaque READY timeout.

Fix: persisted values that config set would reject are treated as unset with a warning; boot falls back to the built-in defaults. Covered by new CLI integration tests driving the real binary against planted config.toml files.

4. atomic_write_toml was atomic but not durable

Failure state: A state/config write completes (config set prints saved:), then the host crashes before the directory entry reaches disk. → The rename lives in the parent directory, which was never fsynced, so the old file resurfaces after reboot — an acknowledged write is lost.

Fix: fsync the parent directory after the rename.

5. Lifecycle proof erased the developer's real config (script)

Failure state: A developer with persisted VM settings runs scripts/minvmd-lifecycle.sh locally. → The EXIT-trap teardown rm -fs the default provider's config.toml unconditionally, permanently deleting their real resource configuration. Separately, an ambient MINVMD_VM_RAM_MIB in the caller's shell out-ranks the persisted layer and fails the proof's ram_mib_source == "config" assertion for reasons unrelated to the code under proof.

Fix: back up any pre-existing config.toml into the proof's scratch dir and restore it on exit (CI runners have none, so teardown still just drops the proof's own file); unset MINVMD_VM_RAM_MIB MINVMD_VM_VCPUS before the assertions.

Bonus: tracing diagnostics corrupted piped JSON

Failure state (exposed by the new tests): any code path emits a tracing warning while minvmd config show --json or minvmd status --json runs (e.g. the malformed-config fallback). → fmt::layer() wrote to stdout, so the warning lands in front of the JSON document and minvmd … --json | jq fails to parse. In run --detach, diagnostics went to /dev/null (stdout) instead of the run.log that captures stderr as the documented boot-failure diagnosis channel.

Fix: route the tracing subscriber to stderr.

Not addressed (from the same review)

• The suggestion to lower the CLI test's RAM value to 512 MiB rests on a wrong premise — over-allocation warns, it never rejects, so 3072 passes on any runner.
• The standalone doc findings (stale reactive-warning user story, undefined R9.1 anchors) are left for a separate docs pass; this PR only updates spec prose the code changes made stale.

Testing

• cargo test -p minvmd — 127 lib + 6 CLI-integration tests pass (3 new resolution/sanitize unit tests; 2 new CLI tests for malformed / hand-edited-invalid config.toml).
• cargo clippy -p minvmd --all-targets -- -D warnings clean; cargo fmt applied; bash -n on the script.
• The snapshot handoff on a real boot needs the gated VM lanes (MINVMD_E2E=1 / scripts/minvmd-lifecycle.sh), which CI exercises on the KVM lane.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • VM boots now use a consistent snapshot of configured CPU and memory resources throughout startup.
  • config show reports the resolved resource values and whether they come from environment settings, saved configuration, or defaults.

• Bug Fixes

  • Invalid or malformed saved resource settings now safely fall back to defaults.
  • Runtime status remains aligned with the resources used at boot.
  • Diagnostic output no longer interferes with JSON command results.

• Reliability

  • Configuration state is written more durably to reduce data loss after interruptions.