Track a reusable image-backed sandbox runtime and standalone NVX implementation #535

Goal

Build a runnable NVX-only image-backed sandbox and reusable nvx-rs host/guest libraries that other runtimes can compose behind their own application transports. The standalone implementation must exercise the same essential cold-start, exec, and image-independent platform-restore mechanics as a richer consumer: read-only image layers plus a tmpfs or ext4-scratch writable root; safe host mappings and enforced network policy; one active exec with bounded waiting; bidirectional credit-based stdin/stdout/stderr without a total output cap; authenticated readiness, logs, stop, and verified recovery. A platform template is captured before image binding, overlay assembly, and exec and is reused across authorized images and policies within one immutable compatibility key. No device hotplug or workload-after-exec snapshots.

A standalone caller may supply an explicitly approved local image and policy; generic NVX code must not silently substitute for a product's image registry, authorization decisions, error model, or deployment modes. The shared root/process/policy mechanics must remain transport-neutral; a small NVXC adapter makes the NVX-only profile runnable. Other callers may use a different application transport without importing it into the small static guest core.

Builds on, rather than replacing

The proposed replaceable region in NVX's filesystem/agent design is a later delivery optimization; first prove an authenticated activation RPC and a real restore. Phase #542 also owns the missing OpenVMM and guest-capture work for pre-image, pre-overlay, pre-exec platform-tier templates with both a blockless RAM-upper template and a scratch-only pre-image ext4 template with fresh scratch, without binding any lower image in either capture. Each upper has its own compatibility key; restored scratch is never reused from capture or another workload. The multi-slot PRs are useful references, not merge prerequisites; #542 owns the independent one-slot implementation and both tiered capture modes. Its minimum VMM contract is a stable, preexisting empty read-only image0 role, authenticated bind-once/query against the actual opened media, guest capacity/partition discovery and a versioned one-slot snapshot key. It has no image1-3, slot-prefix expansion or device hotplug; ordinary direct-image cold boots remain slot-free. Workload-after-exec snapshots are out of scope.

Phases and dependencies

Each phase has its own issue and acceptance gate. Host, guest and exec foundations can advance in parallel after their respective upstream work. Independent VMM #547 (no virtio-fs device on zero-export direct cold) and #548 (actual opened-object receipts and pinned-vs-live grants) must land before #541 cold acceptance; #548 also protects restored attachment acceptance. Dormant-aggregate #540 and fixed-NIC #536 can advance alongside #542 image-only RPC restore. Their implementation belongs in OpenVMM even though NVX tracks its source pin and integration here. Prerequisite gates are not circular acceptance gates: #538/#539/#537 close on composable core behavior exercised by small independent test adapters; #541 then runs the real standalone adapter, and #545 closes the roadmap only after actual second-consumer adoption and deletion evidence. #540/#536 close on reviewed VMM primitive tests; #543 owns their combined NVX guest-activated mapped/networked restore proof. The VMM image-slot, aggregate, NIC and later region changes must be composed into one reviewed, source-pinned revision without rolling back features already on dev.

End-to-end acceptance

• A source-matched NVX-only host/guest bundle runs cold and restored image-backed workloads on supported hypervisors, with equivalent validated root/process/stdio/map/network semantics regardless of application adapter. Pre-workload platform restores prove both a blockless RAM-upper template and a distinct fresh-ext4-scratch template, with no dummy scratch on the RAM path or retained scratch contents on the ext4 path. The single GPT image supplies ordered read-only partitions; writable scratch is a separate device, not another image slot.
• The NVX-only adapter and an independently built downstream adapter use the same pinned NVX host/guest mechanisms and pass shared cold/restore/exec conformance cases; keeping a second process, rootfs, credit or policy implementation does not satisfy this roadmap (nvx-rs: prove shared host and guest mechanics through two independent adapters #545).
• Record source-matched cold-to-Ready, restore-to-Ready and exec-start p50/p95, guest ELF/initramfs size and bounded memory; agree regression budgets before acceptance. The no-map/no-network single-workload cold path does not pay for additional virtio-fs/NIC/image-slot devices, mapping work, or large artifact hashes on start/exec.
• The standalone implementation exposes readiness/build identity, bounded guest logs distinct from exec output, stop, diagnostics and verified restart/recovery. Product-specific registry, authorization, and other cloud deployment modes remain outside the core.
• No-network cold boot proves in both VMM and guest device inventories that no unnecessary NIC/filesystem/image-slot device exists (OpenVMM prerequisite: omit dormant virtio-fs on direct no-map cold boots #547); omitting --mount alone does not omit the current VMM's dormant virtio-fs slot. A reusable platform template instead declares exactly one bind-once image slot (image0), no image1-image3 or multi-slot prefix, plus its fixed dormant filesystem/NIC topology. Authorized network policy is enforced before restored vCPUs run. Zero host mappings are valid in the new activation profile.
• One exec is active; cross-process overlapping requests have finite admission and queue-wait bounds, including when the broker has one host slot. Stop takes priority, cancels waiters and attempts graceful guest shutdown; if an active exec holds the sole slot, it may terminate only the verified VM after a bounded timeout. Both new host/guest paths use bidirectional credits and unbounded total output with bounded in-flight memory; retain old NVXC v1 semantics only for explicitly supported old bundles.
• An object-pinned cold image or mapped root must match the actual VMM-opened handle and OpenVMM prerequisite: verify and receipt opened host attachments #548 receipt before Ready; an object-pinned file child cannot silently follow a new object after attachment, while explicit live-path grants keep their current replacement semantics. An explicitly requested restore fails closed instead of silently cold-booting. Cross-image and cross-policy restores require live hypervisor evidence; an ignored test or image-only proof is not full acceptance.