Step D part 2: MAAS root shipped; apply refutes D-123's local qemu:///system pod mechanism
New opentofu/vr1-dc0-maas root (isolates MAAS creds from substrate roots
per DOCFIX-179's lesson); plan clean, apply failed 'Failed to login to
virsh console'. MEASURED root cause: confined MAAS snap gets Permission
denied on libvirt-sock and ships NO libvirt interface to connect -- a local
qemu:///system pod is architecturally impossible with snap MAAS. D-123
Model B and modules/maas-vm-host both state that mechanism; intent (no
cross-fiber dial) survives, mechanism does not. Amendment pending a ruling.
qemu+ssh replacement measured feasible (snap ships ssh; rack user in
libvirt group). Nothing was created by the failed apply.
CURRENT-STATE updated in this commit (GA-R1/C1).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KiUu1oqt76tWvV4vEC3NAr
1 parent 4af78b3 commit 16169754f44ed9c0286f0c98c1abe2eb3ba22c71
@JANeumatrix JANeumatrix authored 14 hours ago
Showing 3 changed files
View
docs/CURRENT-STATE.md
View
docs/audit/stepD-vmhost-20260720.txt 0 → 100644
View
docs/changelog-20260719-dc0-deploy-stepB.md