Give a deployment a sanctioned way to arm microVM autostart #47

New issue

Open

opened 2026-08-22 00:27:00 +01:00 by allod-agent · 0 comments

allod-agent commented

2026-08-22 00:27:00 +01:00

Member

A deployment that wants a microVM guest to survive a host reboot has no supported place to say so — the only route today is lib.mkForce, learned from a check fixture. Give that decision a named option and a documented home, so arming a real machine is an explicit, greppable act rather than a technique copied out of a test.

Primary goals:

A named per-machine option — a deployment sets one option to arm autostart for one guest, instead of forcing a value the framework already assigned.
The safe default is unchanged — autostart stays off unless a deployment opts in. This adds the interface, not a new default.
Arming stays loud — the act remains deliberate and visible in deployment configuration, greppable by machine name, per allod/strategy#20's human-only gate.
Documented where an operator looks — the recipe lives beside the other per-machine host runtime inputs, not in a check fixture.

Current state and specifics

The pull request allod/archetypes#39 assigns autostart = false for every guest its join creates (flake.nix:986 on agent/microvm-host-guest-join, inside the microvm.vms = lib.mapAttrs … block). It is a plain definition rather than lib.mkDefault, so a deployment's ordinary assignment is a module conflict and only lib.mkForce overrides it. That is consistent with this codebase's practice of making an override of a load-bearing value loud rather than silent, and the default itself is correct: allod/strategy#20's agent gates make "enable microvm autostart for a real machine" a human-only act, so the framework declares a guest without arming it.

What is missing is the operator-facing half. checks/microvm-host-join.nix drives lib.mkForce true and observes its fixture guest entering config.microvm.autostart, which proves the setting is reachable — it does not make a test technique the deployment policy. Neither allod/archetypes nor allod/nexus names a place to put that override, and nothing documents one.

Until it exists, a deployment wanting the reboot recovery its libvirt VMs have today (nixpkgs defaults virtualisation.libvirtd.onBoot to "start", which restores guests that were running before shutdown) must either copy lib.mkForce out of a check fixture or run systemctl start microvm@<name> by hand after every host boot.

Proposed default

Extend nexus.microvm.machines.<name> with an autostart option defaulting to false, and have the allod/archetypes join read it the way it already reads nexus.microvm.hostPlaintextRoot. That surface exists for exactly this class of value — nix/microvm/host.nix:338 describes it as per-machine host runtime data for the microvms declared in microvm.vms, every value deployment composition input — and credentialSources is currently its only member. Keying on the machine name also keeps arming per machine rather than fleet-wide.

The alternative is an allod.archetypes.microvm.* knob alongside volumeImageRoot, which keeps the change in one repo but puts host runtime policy in the guest-composition namespace. Take it only if the cross-repo read proves awkward.

If the option lands in allod/nexus, this is two pull requests rather than one: the arc's implementation sequence requires each source repo's change to be independently reviewable and revertible.

Scope

In: the option declaration, the join reading it, a check proving that a deployment-set value reaches config.microvm.autostart while the default leaves that list empty, and documentation naming where a deployment sets it.

Out: changing the default, which stays false. Out: the microvm.socket export raised as a separate follow-up by the same review. Out: whether any real machine is armed, which is a deployment act under allod/strategy#20's agent gates.

Trigger: this is wanted before the first real microVM machine is expected to survive an unattended host reboot. Until then a manual start after each host boot is an acceptable cost.

Part of allod/strategy#20.

A deployment that wants a microVM guest to survive a host reboot has no supported place to say so — the only route today is `lib.mkForce`, learned from a check fixture. Give that decision a named option and a documented home, so arming a real machine is an explicit, greppable act rather than a technique copied out of a test. Primary goals: - **A named per-machine option** — a deployment sets one option to arm autostart for one guest, instead of forcing a value the framework already assigned. - **The safe default is unchanged** — autostart stays off unless a deployment opts in. This adds the interface, not a new default. - **Arming stays loud** — the act remains deliberate and visible in deployment configuration, greppable by machine name, per `allod/strategy#20`'s human-only gate. - **Documented where an operator looks** — the recipe lives beside the other per-machine host runtime inputs, not in a check fixture. ### Current state and specifics The pull request allod/archetypes#39 assigns `autostart = false` for every guest its join creates (`flake.nix:986` on `agent/microvm-host-guest-join`, inside the `microvm.vms = lib.mapAttrs …` block). It is a plain definition rather than `lib.mkDefault`, so a deployment's ordinary assignment is a module conflict and only `lib.mkForce` overrides it. That is consistent with this codebase's practice of making an override of a load-bearing value loud rather than silent, and the default itself is correct: `allod/strategy#20`'s agent gates make "enable microvm autostart for a real machine" a human-only act, so the framework declares a guest without arming it. What is missing is the operator-facing half. `checks/microvm-host-join.nix` drives `lib.mkForce true` and observes its fixture guest entering `config.microvm.autostart`, which proves the setting is reachable — it does not make a test technique the deployment policy. Neither `allod/archetypes` nor `allod/nexus` names a place to put that override, and nothing documents one. Until it exists, a deployment wanting the reboot recovery its libvirt VMs have today (nixpkgs defaults `virtualisation.libvirtd.onBoot` to `"start"`, which restores guests that were running before shutdown) must either copy `lib.mkForce` out of a check fixture or run `systemctl start microvm@<name>` by hand after every host boot. ### Proposed default Extend `nexus.microvm.machines.<name>` with an `autostart` option defaulting to `false`, and have the `allod/archetypes` join read it the way it already reads `nexus.microvm.hostPlaintextRoot`. That surface exists for exactly this class of value — `nix/microvm/host.nix:338` describes it as per-machine host runtime data for the microvms declared in `microvm.vms`, every value deployment composition input — and `credentialSources` is currently its only member. Keying on the machine name also keeps arming per machine rather than fleet-wide. The alternative is an `allod.archetypes.microvm.*` knob alongside `volumeImageRoot`, which keeps the change in one repo but puts host runtime policy in the guest-composition namespace. Take it only if the cross-repo read proves awkward. If the option lands in `allod/nexus`, this is two pull requests rather than one: the arc's implementation sequence requires each source repo's change to be independently reviewable and revertible. ### Scope In: the option declaration, the join reading it, a check proving that a deployment-set value reaches `config.microvm.autostart` while the default leaves that list empty, and documentation naming where a deployment sets it. Out: changing the default, which stays `false`. Out: the `microvm.socket` export raised as a separate follow-up by the same review. Out: whether any real machine is armed, which is a deployment act under `allod/strategy#20`'s agent gates. Trigger: this is wanted before the first real microVM machine is expected to survive an unattended host reboot. Until then a manual start after each host boot is an acceptable cost. Part of allod/strategy#20.

allod-agent referenced this issue

2026-08-22 00:27:21 +01:00

Wire a microvm guest into the host that starts it #39

allod-agent referenced this issue from allod/strategy

2026-08-22 00:27:26 +01:00

Adopt microvm.nix as a VM runtime in the framework #20