petal-power/wiki-vault
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
4be2c247be
wiki-vault/Sources/Homelab/2026-05-25-pve-memory-and-dns-audit.md

3.0 KiB
Raw Blame History

created path project tags type
2026-05-25 Sources/Homelab homelab-infrastructure
proxmox
tailscale
dns
session-notes

Outcome

Audited herbys-dev memory allocation, confirmed PVE host already has a static IP, and surfaced (but deferred) a Tailscale DNS resilience question.

Topics Covered

  • Docker memory totals on herbys-dev (~2.56 GiB across 16 containers)
  • htop vs PVE memory accounting discrepancy explained (page cache vs process memory)
  • herbys-dev VM right-sized: 24576 MiB → 14336 MiB (applies on next reboot)
  • traefik VM (2 GiB allocated / ~500 MiB used) and knot LXC (512 MiB / ~29 MiB used) reviewed — both left alone
  • PVE host /etc/network/interfaces confirmed: static IP 10.0.21.188/24 on vmbr0, gateway 10.0.21.1, VLAN-aware bridge with vids 2-4094
  • PVE /etc/resolv.conf is managed by Tailscale, pointing at 100.100.100.100
  • Split-DNS confirmed working (resolves both pihole.herbylab.dev → 10.0.11.20 and public domains)

Key Learnings

  • Linux memory accounting: free -h inside the VM is the source of truth. The available column is what matters, not used. PVE's outside view conflates process memory with page cache and shows allocations as "in use" when they're really evictable. The fear-bump from 24 → 26 GiB was based on misreading PVE.
  • VM allocation ≠ host commitment, with a caveat: LXC limits are caps and cost nothing extra. VM allocations are reserved unless ballooning is configured with balloon: set below memory:. Default PVE behavior is effectively no ballooning.
  • memory: in qm config is MiB: 14 GiB = 14336, 12 GiB = 12288.
  • Tailscale --accept-dns=true (default) hijacks /etc/resolv.conf: the daemon rewrites it to point at 100.100.100.100 on every start. --accept-dns=false tells Tailscale to leave DNS config alone, persists across reboots, costs *.ts.net shell resolution but nothing else. VPN tunnel is unrelated to DNS setting.
  • PVE depending on Tailscale for DNS is a resilience smell: a hypervisor that loses DNS when a userland VPN daemon hiccups is a bad pattern. Functional today, worth hardening eventually.
  • Long uptime increases risk over time: untested boot paths, config drift between running state and on-disk state, accumulated updates. Periodic planned reboots are hygiene, not paranoia.

Follow-ons

  • Reboot herbys-dev when convenient to apply the 14 GiB memory change
  • Pre-reboot smoke check: docker ps --format "table {{.Names}}\t{{.Status}}\t{{.RestartPolicy}}" to confirm every container has a restart policy
  • Detach the ubuntu-24.04.4 live-server ISO from VM 100 (ide2 line in qm config) — install cruft, not urgent
  • Optional hardening: switch PVE host off Tailscale DNS. Run tailscale set --accept-dns=false, add dns-nameservers 10.0.11.20 to the vmbr0 stanza in /etc/network/interfaces, then ifreload -a. Removes Tailscale as a DNS dependency for the hypervisor.
  • Try dj0024javia.gitea-vscode-pullrequest extension for VS Code → Lovebug PR review flow without the browser