Skip to content

nvx-rs slimming 3.1.4: run uses the new interface and the CLI's own guest tokens #1109

Closed

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.

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.

  1. SL3.4a1: The shell /init and 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 /init and the fake VMM recognize those settings while the old launch path still works.
    • Contents: guest/common/init reads the blockless mode, the entrypoint and its arguments, the workload identity under the CLI's names, and nvx_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 imports protocol::WORKLOAD_ACCOUNT_TOKEN, which SL6.3 deletes. The fake keeps its emulation of --restore-network-policy, which dev added.
    • Scope:
      • guest/common/init reads the CLI's blockless mode, entrypoint, arguments, workload identity, workload-account request and nvx_share tokens beside the tokens used by old launches.
      • The fake VMM accepts the same CLI tokens, while retaining the old launch forms and --restore-network-policy emulation.
      • The fake VMM defines its own literals for the CLI-owned tokens it emulates and stops importing protocol::WORKLOAD_ACCOUNT_TOKEN from nvx.
    • 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 run or any sandbox command: SL3.4a2 switches run, SL3.4b sandbox run, SL3.5b sandbox start, exec, stop and deprovision, and SL3.5a sandbox provision.
      • A generic token registry or shared parser between shell and Rust: the fake deliberately keeps literals for the small protocol it emulates.
    • Approach: Extend the existing command-line scans in guest/common/init and 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 its tests.rs; the PR explains the flagged fake changes. Do not introduce a new token abstraction or command-line parser.
    • Done when:
      • The shell /init reads 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-policy and imports no CLI-owned token constant from nvx.
    • Needs: nothing.
    • Estimate: 180 core lines, 2 counted files. Past 360 core lines, stop and ask before continuing.
  2. SL3.4a2: run boots blockless VMs through the new APIs, with the CLI's own guest tokens.

    • Objective: run launches 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 a VmConfig and Boot.command_line, which the CLI's guest_tokens renders: the blockless mode, the entrypoint and its arguments, the workload identity under the CLI's own names, and nvx_share from a planned ExportPlan's guest_table() (nvx-rs: plan the shares of run through the export planner #802). run launches through host::vm::{create, spawn, stop}, and passes neither --microvm-lifecycle nor --microvm-workload-identity. run's restore options, --restore-network-policy included, keep the old path until SL3.8b moves --restore-snapshot to the strict path and drops --restore-network-policy.
    • Scope:
      • nvx-rs/src/host/cli/run.rs builds a blockless VmConfig and Boot.command_line for the existing one-shot and managed run modes.
      • The CLI's guest_tokens module renders the mode, entrypoint, arguments, workload identity, workload-account request and each nvx_share row from ExportPlan::guest_table().
      • Cold blockless launches use host::vm::create, host::vm::spawn and host::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-snapshot to 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-lifecycle or --microvm-workload-identity: OpenVMM reserves them, so the CLI uses its own guest tokens.
      • New run flags, modes or output redesigns, and durable launch records, launch retries or recovery after the CLI exits: this PR switches the existing foreground behavior only.
    • Approach: Translate the existing parsed options directly into VmConfig, one planned ExportPlan, and Boot.command_line; let host::vm lower 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_line contains the mode, entrypoint, arguments, workload identity and nvx_share rows from ExportPlan::guest_table().
      • The resulting OpenVMM arguments contain neither --microvm-lifecycle nor --microvm-workload-identity.
      • 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 for the new path.
    • 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.

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

  1. changed the title [-]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[/+] on Nov 3, 2026
  2. esaurez commented on Nov 10, 2026

    @esaurez
    ContributorAuthor

    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.

    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.

  3. ppenna commented on Nov 11, 2026

    @ppenna
    Contributor

    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; dev receives it when feature/nvx-refactor lands there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions