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>
36 lines
2.5 KiB
Markdown
36 lines
2.5 KiB
Markdown
---
|
|
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.
|