Track consolidating NVX host and guest code in the nvx-rs crate #356

Context

aci_edge_sandboxes combines two concerns:

• the ACI Edge Sandboxes contract: the MXC request model and its validation order, the wire error codes, SandboxId, the Backend trait, and the asynchronous and mock APIs; and
• everything it takes to drive NVX: launching OpenVMM, the authenticated NVXS/NVXC control protocol, artifact discovery, process and control-endpoint primitives for Linux and Windows, network and filesystem lowering, bundled-release staging, and a fake OpenVMM for tests.

The same NVX mechanics exist a second time in Python, in control_session.py, sandbox_lifecycle.py, sandbox.py, and egress_policy.py under scripts/nvx_tools/. The guest side of the control protocol is written in C, in guest/common/. A change to the control protocol therefore touches Rust twice (the backend and the fake OpenVMM), Python, and C.

Goal

A new Rust crate, nvx-rs, owns all NVX-specific code and provides:

1. a library, nvx, that aci_edge_sandboxes, the crate's own binaries, and tests build on;
2. six static guest binaries that replace guest/common/*.c under their existing names; and
3. a host CLI, nvx-rs, that becomes the backend of the runtime paths of scripts/nvx.py.

Phases

Each phase is one pull request with its own sub-issue, and the phases merge in order.

The shared image-backed runtime of #535 carries the rest of the consolidation inside nvx-rs: #620 moves the CLI's sandbox lifecycle and host::instance onto one store, supervisor, and NVXS session, and #622 gives them one launch planner.

Decisions

Target layout

nvx-rs/
├── src/
│   ├── protocol/    NVXS records, NVXC frames, EXEC payloads, guest features, and nvx_map tokens;
│   │                no dependencies, shared by the host and the guest
│   ├── contract.rs  control-contract versions and release-manifest compatibility
│   ├── net/         CIDR parsing and subtraction
│   ├── host/        feature `host` (default): artifacts, launch, network, filesystem, session,
│   │                process, platform, VM instances, the sandbox launch profile, and the CLI
│   ├── guest/       feature `guest` (Linux): the managed agent and the guest tools
│   ├── testing/     feature `testing`: the fake OpenVMM
│   └── bin/         nvx-rs, nvx-fake-openvmm, and the six guest binaries
├── build.rs         bundled-release staging, and link arguments for the freestanding nvx-device-io
└── artifacts.json   the NVX release that the `bundled` feature stages

aci_edge_sandboxes keeps the ACI contract: the facade, Backend, capabilities, the MXC model and its validation, error codes, SandboxId, the execution and stream plumbing, and the asynchronous and mock APIs. It also keeps a thin openvmm backend that translates requests into nvx calls and maps nvx errors to ACI error codes.

Validation

Each phase runs:

• nvx.py verify;
• the nvx-rs checks: cargo fmt --check, cargo clippy with -D warnings (all targets and features, and the library without default features), cargo test, cargo doc with -D warnings, and the MSRV check;
• the check-aci-edge-sandboxes, check-quality, and validate-nvx actions; and
• the affected hypervisor tests (test-aci-edge-sandboxes and test-microvm scenarios) on Linux/KVM. CI covers Linux/MSHV and Windows/WHP.

Risks

Acceptance criteria

• Phase 1: aci_edge_sandboxes contains no NVX mechanics beyond translating its requests into nvx calls.
• Phase 2: no C sources remain outside openvmm/, and every guest image ships the Rust binaries at the existing paths.
• Phase 3: Python duplicates no control-protocol, lifecycle, or egress logic, and releases ship nvx-rs.
• Phase 4: nvx.py run goes through nvx-rs, and Python builds no OpenVMM command line for it.
• CI, including the KVM, MSHV, and WHP workloads and the performance gate, passes after each phase.