claude-memory/homeassistant-vm.md at a304b6d197113d9b87b5fb570a5d9e84fdc019ac

Files

T

Andreas WredeandClaude Fable 5 a304b6d197 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>

2026-07-06 18:36:43 -04:00

2.5 KiB

Raw Blame History

name, description, metadata

name

description

metadata

homeassistant-vm

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.

node_type	type	originSessionId
memory	project	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.

2.5 KiB Raw Blame History

2.5 KiB

Raw Blame History