Repository navigation
Description
Parent: #1083, in #1076. Needs: #1100. Unblocks: #1110, #1114, #1116.
Goal. run boots blockless VMs, in both modes, through host::vm::{create, spawn, stop}, with the CLI's own guest tokens: the blockless mode, the entrypoint and its arguments, the workload identity, and nvx_share from a planned export (#802). The shell /init and the fake VMM read those tokens, beside OpenVMM's. OpenVMM's arguments hold neither --microvm-lifecycle nor --microvm-workload-identity.
Notes.
- The shell
/initand the fake VMM read the CLI's tokens beside OpenVMM's, until nvx-rs slimming 4.2.3: the old configs, the old launch code andbundledare gone #1122 deletes the old launch path. The fake keeps its own literals of the CLI-owned tokens that it emulates, so it imports no such token constant fromnvx.
PRs, in order. Each PR has one goal, leaves dev green, and names in its description each old test of its area as kept, rewritten or retired, with each change that check_test_changes.py reports. Its tests follow the repository's test layout: a module's unit tests, and the code that only they use, sit in its tests.rs or tests/ and move with it. The estimates count core lines (code, not comments, docs or tests) and counted files; each PR records its measured values. Each PR does what its Scope says and no more: a case, input or layout that its Scope doesn't name, and whatever "Not in this PR" lists, is out of scope. Address every review comment within the scope, and ask before acting on one that asks for more. A PR whose measured core lines pass the stop that its Estimate names (twice the estimate, at most 600) stops and asks before continuing.
-
SL3.4a1: The shell
/initand the fake VMM read the CLI's own guest tokens.- Objective: Blockless launches can use guest settings owned by the CLI without passing OpenVMM-reserved lifecycle or workload-identity options. The shell
/initand the fake VMM recognize those settings while the old launch path still works. - Contents:
guest/common/initreads the blockless mode, the entrypoint and its arguments, the workload identity under the CLI's names, andnvx_share, beside OpenVMM's tokens until SL6.3 deletes the old launch path. The fake VMM reads the same tokens beside the old launches', while their tests remain, and keeps its own literals of the NVX-only tokens that it emulates, so it no longer importsprotocol::WORKLOAD_ACCOUNT_TOKEN, which SL6.3 deletes. The fake keeps its emulation of--restore-network-policy, whichdevadded. - Scope:
guest/common/initreads the CLI's blockless mode, entrypoint, arguments, workload identity, workload-account request andnvx_sharetokens beside the tokens used by old launches.- The fake VMM accepts the same CLI tokens, while retaining the old launch forms and
--restore-network-policyemulation. - The fake VMM defines its own literals for the CLI-owned tokens it emulates and stops importing
protocol::WORKLOAD_ACCOUNT_TOKENfromnvx.
- Not in this PR:
- Deleting the old launch-token path from
/init: SL6.3 does that after its callers move; the fake VMM keeps the old launch forms that its tests cover. - Changing layered-root routing to nvx-init: SL7.8a owns that switch.
- Changing
runor any sandbox command: SL3.4a2 switchesrun, SL3.4bsandbox run, SL3.5bsandbox start,exec,stopanddeprovision, and SL3.5asandbox provision. - A generic token registry or shared parser between shell and Rust: the fake deliberately keeps literals for the small protocol it emulates.
- Deleting the old launch-token path from
- Approach: Extend the existing command-line scans in
guest/common/initand the fake VMM's existing token validation. Keep old and new names side by side, use local constants in the fake, and add cases in itstests.rs; the PR explains the flagged fake changes. Do not introduce a new token abstraction or command-line parser. - Done when:
- The shell
/initreads every CLI-owned blockless launch token in both blockless modes. - The fake VMM accepts the CLI token launches and the old launches that remain.
- The fake VMM still accepts
--restore-network-policyand imports no CLI-owned token constant fromnvx.
- The shell
- Needs: nothing.
- Estimate: 180 core lines, 2 counted files. Past 360 core lines, stop and ask before continuing.
- Objective: Blockless launches can use guest settings owned by the CLI without passing OpenVMM-reserved lifecycle or workload-identity options. The shell
-
SL3.4a2:
runboots blockless VMs through the new APIs, with the CLI's own guest tokens.- Objective:
runlaunches both blockless modes through the new VM lifecycle and supplies guest settings through CLI-owned tokens. OpenVMM receives neither of its reserved lifecycle or workload-identity options. - Contents:
run, blockless, in both modes: its options build aVmConfigandBoot.command_line, which the CLI'sguest_tokensrenders: the blockless mode, the entrypoint and its arguments, the workload identity under the CLI's own names, andnvx_sharefrom a plannedExportPlan'sguest_table()(nvx-rs: plan the shares ofrunthrough the export planner #802).runlaunches throughhost::vm::{create, spawn, stop}, and passes neither--microvm-lifecyclenor--microvm-workload-identity.run's restore options,--restore-network-policyincluded, keep the old path until SL3.8b moves--restore-snapshotto the strict path and drops--restore-network-policy. - Scope:
nvx-rs/src/host/cli/run.rsbuilds a blocklessVmConfigandBoot.command_linefor the existing one-shot and managedrunmodes.- The CLI's
guest_tokensmodule renders the mode, entrypoint, arguments, workload identity, workload-account request and eachnvx_sharerow fromExportPlan::guest_table(). - Cold blockless launches use
host::vm::create,host::vm::spawnandhost::vm::stop, with the existing dry-run and outcome behavior covered by rewritten tests. - The existing restore options, including
--restore-network-policy, remain on their old path until SL3.8b.
- Not in this PR:
- Moving
--restore-snapshotto the strict restore path or removing--restore-network-policy: SL3.8b does both. - Changing sandbox commands or layered roots: SL3.5b and SL3.4b own those launches.
- Passing
--microvm-lifecycleor--microvm-workload-identity: OpenVMM reserves them, so the CLI uses its own guest tokens. - New
runflags, modes or output redesigns, and durable launch records, launch retries or recovery after the CLI exits: this PR switches the existing foreground behavior only.
- Moving
- Approach: Translate the existing parsed options directly into
VmConfig, one plannedExportPlan, andBoot.command_line; lethost::vmlower the configuration. Reuse the current share planner and CLI tests, and keep restore branching intact rather than building a second launch framework or compatibility layer. - Done when:
- Both blockless modes launch through
host::vm::{create, spawn, stop}. Boot.command_linecontains the mode, entrypoint, arguments, workload identity andnvx_sharerows fromExportPlan::guest_table().- The resulting OpenVMM arguments contain neither
--microvm-lifecyclenor--microvm-workload-identity. dry_runs_print_the_openvmm_command_and_launch_nothingandthe_openvmm_command_of_a_run_splits_back_into_its_argumentsare kept or rewritten for the new path.
- Both blockless modes launch through
- Needs: SL3.4a1, above; SL2.10, in nvx-rs slimming 2.2.2: a VM stops only with a proved exit, and can be reattached #1100.
- Estimate: 320 core lines, 5 counted files. Past 600 core lines, stop and ask before continuing.
- Objective:
Tests. run, in both blockless modes: the shell /init reads each of the CLI's tokens; Boot.command_line holds the mode, the entrypoint and its arguments, the workload identity and nvx_share from ExportPlan::guest_table(); and OpenVMM's arguments hold neither --microvm-lifecycle nor --microvm-workload-identity. The fake VMM accepts the CLI's token-based launches and the old launches that remain, and imports no NVX-only token from nvx. The CLI tests of run, such as dry_runs_print_the_openvmm_command_and_launch_nothing and the_openvmm_command_of_a_run_splits_back_into_its_arguments, are kept or rewritten.
Done when: every PR above has merged, with dev green.
Activity
[-]nvx-rs slimming 3.1.4: `run` uses the new interface and nvx-cli's own guest tokens[/-][+]nvx-rs slimming 3.1.4: `run` uses the new interface and the CLI's own guest tokens[/+]esaurez commentedon Nov 10, 2026
Workstream source/progress checkpoint - 2026-11-11 UTC
Checked boxes below mean merged scope, not merely an implemented first iteration. Implementation branches are source checkpoints, not automatic qualification, Ready or merge approval. Some starting inputs are frozen/anonymous commits rather than standalone branches; their exact SHAs and known merged producer refs are recorded explicitly.
SL3.4a1 - merged via pull request 1271.
esaurez/slim-3.1.4-sl3.4a1-20261103ata795cf4488cb5a56635095c3891b215d3599f620.feature/nvx-refactorat1e23a5dfc1dfee30262edd713a85a4e4fa9eef2d; merge commit8e0ca89f0e0c60bb2dfe25347787a5a378bfe1e2.SL3.4a2 - pull request 1441: Draft handed off to Pedro Henrique Penna (@ppenna); not merged.
f346df02d0bb7fec4b3f3461243a9cb312b3c1a0. Remaining CI and review blockers are documented in the PR; this handoff is not a CI-pass or merge claim.esaurez/slim-3.1.4-sl3.4a2-20261108; exact headdbd78d9beea69232f25df8d089963b5397bbb36d.esaurez/slim-2.2.2-sl2.10-20261107; exact commit7bca08c599cd70453a3e99c2409b314f599429e8.The original technical scope remains authoritative, supplemented only by any portable technical clarification in this issue. No machine-specific execution policy is part of this checkpoint.
ppenna commentedon Nov 11, 2026
Both PRs of this group have merged into
feature/nvx-refactor: SL3.4a1 (#1271) and SL3.4a2 (#1441).The feature branch's post-merge CI run at
394c89025e, which contains all of them, passed: https://github.com/microsoft/nvx/actions/runs/42952780739. Closing this group as complete;devreceives it whenfeature/nvx-refactorlands there.