Set static IPs in PVE LXCs and configure local DNS in Adguard #36
Labels
No labels
blocked
needs-manual-review
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
matt/homelab-docker#36
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Problem
All LXC containers on Proxmox use DHCP. After a power outage or reboot, IPs can change, breaking every service link in Dashy, Komodo, and bookmarks.
Adguard is currently at 192.168.1.86 (expected .95 — already drifted once).
Fix
Step 1 — Static IPs inside each PVE LXC
PVE web UI → select LXC → Network → edit eth0 → change DHCP to Static:
Restart each LXC after saving. Nexus/PVE/PBS are physical — set via /etc/netplan/.
Step 2 — DNS rewrites in Adguard Home (192.168.1.86)
Filters → DNS Rewrites → Add rewrite:
Step 3 — Point router DNS at Adguard
Verizon Fios router (192.168.1.1) → DNS:
Step 4 (optional follow-up) — Update Dashy to use .lan hostnames
After DNS is confirmed working, open a PR to update dashy/conf.yml replacing IPs with .lan names. That work is already started on branch feature/dashy-lan-hostnames.
No git PR needed
This is all UI/config work. No compose files change.
New incident: 2026-07-03/04 power outage — DHCP conflict on Dispatcharr
After last night's outage, PVE/Nexus/Atlas all shut down cleanly via NUT and came back fine. Dispatcharr (LXC 113) came back up as a container but wasn't network-reachable.
Root cause: IP conflict on 192.168.1.254. ARP from both Atlas and Nexus resolves
.254to MAC38:94:ed:52:73:92, not the LXC's actual interface MAC (bc:24:11:0a:3b:15, Proxmox OUI). Some other device grabbed.254via DHCP during the mass-reboot renegotiation, and it's now shadowing the LXC.This confirms the exact risk this issue was opened for — DHCP-assigned services drift/conflict after reboots. Dispatcharr wasn't in the original static-IP table (it didn't exist yet when this issue was filed). Since Dispatcharr backs Jellyfin's live TV channels, a silent IP conflict here breaks Jellyfin, not just Dispatcharr's own UI.
Add to the static IP table:
Also worth reviewing whether
.254is a good static choice long-term (near top of DHCP range on many routers — worth checking the router's DHCP pool bounds/reservations to make sure it's excluded from the dynamic pool once set static, or this will keep recurring).Also set
onboot: 1on LXC 113 (done manually today, but should be part of the standard checklist for every LXC in this issue).2026-07-07 update: Converted Dispatcharr (PVE LXC 113) from DHCP to a static IP:
Confirmed after reboot:
192.168.1.254/24withvalid_lft forever(no DHCP lease), no dhclient process running. Dispatcharr and its Komodo Periphery agent both came back up healthy (HTTP 200 on :9191).However, this did NOT fix a separate issue found during the same investigation: the Komodo Periphery↔Core websocket connection for this LXC still reconnects every ~60-90s (
Timed out waiting for Ping: deadline has elapsed), even after the static IP was applied and the container rebooted. So the DHCP conflict was likely the cause of the full 7/3-7/4 outage, but this ongoing low-grade flapping looks like a separate, still-unresolved network or Komodo config issue. Would need a packet capture during an actual disconnect to pin down further.Practical impact is now contained regardless: as part of the same session, Dispatcharr was split out of the shared Komodo "Deploy Stacks" procedure into its own "Deploy Dispatcharr" procedure, so this flapping can no longer silently block deploys of unrelated stacks (Home Assistant, Tandoor, etc.) the way it had 2-3 times previously.
No Jellyfin changes needed — Dispatcharr's IP did not change (was already .254, just DHCP-leased before), and Jellyfin talks directly to Dispatcharr's stream port (9191), not through Komodo, so it was unaffected throughout.