Document pve-test's wifi-primary network and add Claude node guardrails

pve-test was briefly clustered with pve1 then deliberately de-clustered
so it could move to wifi-primary networking (4addr bridge mode, bonded
with a wired LAN backup) - a change not achievable while clustered given
corosync's latency requirements. Captures that as a reproducible script
plus docs: cluster separation procedure, the wifi network design and the
live-cutover pitfalls hit along the way, and node-role/history context.

Also adds CLAUDE.md guardrails for pve1 (production) vs pve-test
(sandbox) - this repo had none before, despite scripts here being able
to make real changes to both.

Separately: both nodes' mgmt firewalls were dropping ICMP by default
(TCP 22/8006 only), which looked like an outage mid-troubleshooting even
though SSH/web UI were fine. Added an explicit ping-allow rule to the
firewall template, applied it live on both nodes, and added an audit.sh
check so it stays enforced.
This commit is contained in:
2026-07-21 21:20:27 +00:00
parent 8c5b76cb15
commit ba73420350
10 changed files with 553 additions and 5 deletions
+10
View File
@@ -59,6 +59,16 @@ require or assume the split-disk/multi-NIC layout Stage 2 wants.
Everything below this point is the target design for when nodes 2 and 3
are actually being provisioned. Not applicable to `pve1` as it stands.
**`pve-test` existing does not mean node 2 exists.** A second physical
node (`pve-test`) does run alongside `pve1` — see `05-node-roles.md`
but it's a sandbox/test box, not built to this Stage 2 design, and as of
this writing runs on **wifi** networking
(`06-pve-test-wifi-network.md`), which is directly incompatible with
corosync's latency/jitter requirements below. `pve-test` and `pve1` were
briefly clustered and then deliberately de-clustered for exactly this
reason. Don't treat `pve-test` as progress toward Stage 2 without a
deliberate decision to rebuild its networking first.
### End goal
3-node Proxmox VE cluster with HA-managed VMs backed by **Ceph** — true