alexion/dotfiles
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(guests): keep a networked guest's resolver and order it after its bridge #36

Merged
alexion merged 2 commits from task-0010-guest-vm-integration-test into main 2026-07-26 08:08:25 -04:00
Conversation 0 Commits 2 Files Changed 3 +82 -3
alexion commented 2026-07-25 23:04:00 -04:00
Owner
Copy Link

Summary

Two fixes to the guest builder, both for a guest placed on a VLAN.
Neither has a committed user yet — the repo's only host is a laptop with no bridge — so both are latent until a real host carries a networked guest, but each fails or races that guest today.

  • Keep the guest's own resolver. A networked guest runs its own networkd, which default-enables systemd-resolved. That conflicts with the nested-container default of inheriting the host's resolv.conf, and the guest's toplevel failed to build with "Using host resolv.conf is not supported with systemd-resolved". Fixed with networking.useHostResolvConf = false in guestNet.
  • Order the guest after its bridge. The container enslaves its veth to the br-vlan<id> bridge at start, but the container backend orders the unit only after the network is up, not after that specific bridge exists — a race the enslavement could lose. The container@<name> unit now orders after/wants the bridge's device unit when the guest is networked.

How these surfaced

Both came out of a NixOS VM integration test written for the guests spec's testing decisions.
The test was built and passed, then removed on review: its regression value over the existing toplevel-eval seam is thin (much of what it asserted is upstream 802.1Q/nspawn/DHCP behaviour, not this flake's code), it cost a full QEMU boot on every nix flake check, and its scaffolding exercised a construction of a guest that does not match how one is really deployed.
The two real defects it surfaced were worth keeping, so they were folded into the builder here.
Reintroducing the VM seam is the right move once a real host carries a networked, pool-backed guest, at which point booting that host is the honest test.
The task file carries the full rationale.

Verification

  • nix flake check passes.
  • A committed (non-networked) guest's container@ unit is unchanged: after/wants hold only network.target.
  • A networked guest (checked via extendModules with vlan = 10) gains sys-subsystem-net-devices-br\x2dvlan10.device in both after and wants, and resolves its own resolver.

Also includes an unrelated repo gotcha: this flake pins no Nix formatter and its committed .nix files are not nixfmt-rfc-style-clean, so a blind nixfmt reflows untouched code.

— Claude

## Summary Two fixes to the `guest` builder, both for a guest placed on a VLAN. Neither has a committed user yet — the repo's only host is a laptop with no bridge — so both are latent until a real host carries a networked guest, but each fails or races that guest today. - **Keep the guest's own resolver.** A networked guest runs its own networkd, which default-enables systemd-resolved. That conflicts with the nested-container default of inheriting the host's `resolv.conf`, and the guest's toplevel failed to build with "Using host resolv.conf is not supported with systemd-resolved". Fixed with `networking.useHostResolvConf = false` in `guestNet`. - **Order the guest after its bridge.** The container enslaves its veth to the `br-vlan<id>` bridge at start, but the container backend orders the unit only after the network is up, not after that specific bridge exists — a race the enslavement could lose. The `container@<name>` unit now orders `after`/`wants` the bridge's device unit when the guest is networked. ## How these surfaced Both came out of a NixOS VM integration test written for the guests spec's testing decisions. The test was built and passed, then removed on review: its regression value over the existing toplevel-eval seam is thin (much of what it asserted is upstream 802.1Q/nspawn/DHCP behaviour, not this flake's code), it cost a full QEMU boot on every `nix flake check`, and its scaffolding exercised a construction of a guest that does not match how one is really deployed. The two real defects it surfaced were worth keeping, so they were folded into the builder here. Reintroducing the VM seam is the right move once a real host carries a networked, pool-backed guest, at which point booting that host is the honest test. The task file carries the full rationale. ## Verification - `nix flake check` passes. - A committed (non-networked) guest's `container@` unit is unchanged: `after`/`wants` hold only `network.target`. - A networked guest (checked via `extendModules` with `vlan = 10`) gains `sys-subsystem-net-devices-br\x2dvlan10.device` in both `after` and `wants`, and resolves its own resolver. Also includes an unrelated repo gotcha: this flake pins no Nix formatter and its committed `.nix` files are not `nixfmt-rfc-style`-clean, so a blind `nixfmt` reflows untouched code. — Claude
alexion added 2 commits 2026-07-26 00:01:18 -04:00
fix(guests): keep a networked guest's resolver and order it after its bridge (task 0010) 53a070a59a 
A guest placed on a VLAN runs its own networkd, which default-enables
systemd-resolved. That conflicts with the nested-container default of
inheriting the host's resolv.conf, so its toplevel failed to build; keep the
guest's own resolver with networking.useHostResolvConf = false.

The same guest's container enslaves its veth to the VLAN bridge at start,
but the container backend orders the unit only after the network is up, not
after that specific bridge exists — a race the veth enslavement could lose.
Order container@<name> after the br-vlan<id> device so the bridge is there
first.

Both were surfaced by a VM integration test that was explored and then
dropped as not worth its regression cost; the task file records the call.
docs: note the repo pins no formatter and nix files aren't nixfmt-clean f218e47814 
Record a gotcha so a future change does not run nixfmt across a file and
reflow untouched code, injecting churn unrelated to the change.
alexion force-pushed task-0010-guest-vm-integration-test from 7d1f674aeb to f218e47814 2026-07-26 00:01:18 -04:00 Compare
alexion changed title from test(guests): boot a guest end to end in a VM (task 0010) to fix(guests): keep a networked guest's resolver and order it after its bridge 2026-07-26 00:01:48 -04:00
alexion merged commit f218e47814 into main 2026-07-26 08:08:25 -04:00
alexion deleted branch task-0010-guest-vm-integration-test 2026-07-26 08:08:25 -04:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
alexion
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: alexion/dotfiles#36
Delete Branch "task-0010-guest-vm-integration-test"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?