memory: initial import (transferred from wayback) + hub-move and cockpit-EMFILE updates

Snapshot of the Pi 'wan' Claude memory: wayback van-router build notes, ZT DNS,
HA VM, LAN port, and the Pi port memory updated for the 2026-07-06 USB hub move
(AP live on the Pi) and the cockpit-bridge fd-limit fix.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Andreas Wrede
2026-07-06 18:36:43 -04:00
co-authored by Claude Fable 5
commit a304b6d197
7 changed files with 225 additions and 0 deletions
+35
View File
@@ -0,0 +1,35 @@
---
name: homeassistant-vm
description: "Home Assistant OS runs as a libvirt/KVM VM (ha_van) bridged onto br0 at 10.42.0.50; how it's networked and reached."
metadata:
node_type: memory
type: project
originSessionId: 2a8455f6-a504-4683-b972-73a2930ce600
---
Home Assistant OS runs as a KVM VM on wayback, installed 2026-06-29 per the official
linux/virt-install docs. **Re-plumbed 2026-07-06: NIC bridged onto `br0`** (commit `a7819ed`
in [[wayback-campervan-ap]] `~/vanlink`, dir `ha/`, README §3 "Home Assistant VM").
- **Domain:** `ha_van` (libvirt/qemu), autostart enabled. 4 GB RAM, 2 vCPU, 32 GB disk.
Disk: `/var/lib/libvirt/images/haos_ova-17.3.qcow2` (scsi/virtio-scsi, UEFI non-secureboot
OVMF `/usr/share/OVMF/OVMF_CODE_4M.fd`). HAOS **17.3** — 18.0 was pulled from stable (bug #4811).
Domain XML reference copy: `~/vanlink/ha/ha_van.xml`.
- **Networking = bridged into `br0`** (`<interface type='bridge'>`, model **virtio** — was e1000,
HAOS took the change without complaint). MAC `52:54:00:ad:0a:01`, pinned lease **10.42.0.50**
+ DNS name `homeassistant` via `dhcp-host` in van-ap dnsmasq (`~/vanlink/ap/van-ap-dnsmasq.conf`).
First-class LAN device: mDNS/SSDP discovery works, HA sees real client IPs.
- **URLs:** `http://10.42.0.50:8123`, `http://homeassistant:8123`, `homeassistant.local` (mDNS),
and the legacy `http://10.42.0.1:8123` — kept working via nft DNAT in `ap/nftables.conf` plus a
hairpin masquerade for same-subnet clients (VM would otherwise reply directly on br0 from .50
and the client, expecting .1, drops it). ZT clients: all of the above work — the ZT network
(nwid d3ecf5726d041b2a) publishes a managed route `10.42.0.0/24 -> 192.168.196.22`
(controller-side); VM replies route back through its gateway 10.42.0.1, symmetric, no masquerade.
- **Why bridged (history):** it originally sat on libvirt's `default` NAT net (192.168.122.50)
with a `/etc/libvirt/hooks/network` hook inserting FORWARD ACCEPTs above libvirt's
`LIBVIRT_FWI` REJECT. **That rotted**: a libvirtd restart re-inserts libvirt's chain jumps at
the top of FORWARD *without firing the network hook*, pushing the ACCEPTs below the REJECT —
found dead 2026-07-06 (0 pkts on both ACCEPTs). Bridging removed the failure mode. The hook,
the 192.168.122.50 reservation, and the iptables rules are deleted.
- Cockpit "Virtual Machines" page requires `cockpit-machines` (installed). `br_netfilter` is not
loaded, so client↔VM L2 traffic on br0 never touches iptables/nftables.