fv-ml1: complete the cutover — rename, renumber, DNS, and the LiteLLM repoint
The box is physically at Fountain Valley, renamed, renumbered onto 10.251/16, and serving inference again. This lands the repo half of that. Host: hostname ana-ml2 -> fv-ml1, pinned to 10.251.50.54 by a dnsmasq reservation so the address the runbook, DNS and LiteLLM all assume is the address it actually has. Its headscale node is renamed too. The sweep ran from scripts/fv-ml1-rename-sweep.sh, whose allowlist is the reason this diff touches current-state files and not the record. Dated persistent-memory entries, archival-memory and incident notes still say ana-ml2 in 31 and 62 places respectively, because that is what the box was when those things happened. Rewriting them would make the history lie. LiteLLM was the load-bearing piece and needed more than the api_base sed the runbook describes. Twenty api_base entries repointed, but a grep-and-verify pass also caught a LIVE pass_through_endpoints target for the scalar-judge reward route still on the old address -- an api_base-only substitution would have left it dead. Four prose references describing current state were repointed as well; one historical note recording where a hand-test was run is deliberately left pointing at 10.250.50.54. Two facts in the server tables were wrong and are corrected here. The site is Fountain Valley, not Anaheim. And the box has FOUR RTX PRO 6000 Blackwell Max-Q, not two -- verified by nvidia-smi -L and independently by PCI enumeration of four GB202GL devices. That is 391 GB of VRAM rather than 196, which changes what fits on it. DNS: fv-ml1, fv-ml1-bmc and fv-gw added under the fv site via the piggyback approach, scriberr re-homed, and the ana-ml2 records removed. Applied to all three resolvers. The BMC record carries a warning that its 802.1q VLAN tag must stay disabled -- it shipped tagging VLAN 250 into an untagged port, which made it invisible to every network-side diagnostic and is the reason it appeared dead through several cable changes. Verified end to end: summarizer and sec both answer through the Anaheim gateway across the mesh to FV seats on different ports.
This commit is contained in:
@@ -1 +0,0 @@
|
||||
10.250.50.54
|
||||
@@ -1,13 +1,13 @@
|
||||
# ana-ml2
|
||||
# fv-ml1
|
||||
|
||||
Primary AI inference host for PFI.
|
||||
|
||||
## Network
|
||||
|
||||
- **LAN IP:** 10.250.50.54 (in-band, OS-side)
|
||||
- **BMC (OOB):** 10.250.250.50 — Supermicro IPMI web UI
|
||||
at <https://10.250.250.50> (homepage card: *PFI-ANA-ML2 BMC*)
|
||||
- **SSH:** standard port 22 on 10.250.50.54
|
||||
- **LAN IP:** 10.251.50.54 (in-band, OS-side)
|
||||
- **BMC (OOB):** 10.251.250.50 — Supermicro IPMI web UI
|
||||
at <https://10.251.250.50> (homepage card: *PFI-ANA-ML2 BMC*)
|
||||
- **SSH:** standard port 22 on 10.251.50.54
|
||||
|
||||
## Hardware
|
||||
|
||||
@@ -54,9 +54,9 @@ history, not an active fault, and the 2 CKSUM were the stale-block artefact of t
|
||||
replace on growth** (`zpool replace tank nvme7n1 <new>`; any PM1725b 1.6 TB or
|
||||
larger). Slot 0-5 itself deserves a reseat / cable check at the next hands-on
|
||||
visit — a bay that dropped a drive for 4½ months is the likelier fault than the
|
||||
drive. Playbook: `playbooks/ana-ml2-pool-health.yaml` (idempotent; rerunning is a
|
||||
drive. Playbook: `playbooks/fv-ml1-pool-health.yaml` (idempotent; rerunning is a
|
||||
no-op). ⚠ **Nothing alerts on this** — see the open follow-up in
|
||||
`persistent-memory.d/2026-09-09-ana-ml2-pool-actions-done.md`.
|
||||
`persistent-memory.d/2026-09-09-fv-ml1-pool-actions-done.md`.
|
||||
|
||||
## Key paths
|
||||
|
||||
@@ -119,7 +119,7 @@ seats, safe to leave: `mistral-medium-3.5`, `mistral-small-4(-heretic)`,
|
||||
## Refresh state
|
||||
|
||||
```bash
|
||||
scripts/refresh-server-info.sh ana-ml2
|
||||
scripts/refresh-server-info.sh fv-ml1
|
||||
```
|
||||
|
||||
Latest snapshot: `system-details.txt` (regenerate as needed).
|
||||
@@ -0,0 +1 @@
|
||||
10.251.50.54
|
||||
@@ -40,7 +40,7 @@ hypervisor):
|
||||
- **CT 112** — `ana-filebot` (file-task automation) — `servers/ana-filebot/`
|
||||
- **CT 113** — `ana-wg` (WireGuard VPN) — `servers/ana-wg/`
|
||||
|
||||
`ana-ml2` (`10.250.50.54`) is a separate bare-metal Supermicro box,
|
||||
`fv-ml1` (`10.251.50.54`) is a separate bare-metal Supermicro box,
|
||||
not on this hypervisor. `sfsrv-ana` (`10.250.250.115`) runs on a
|
||||
separate Dell R630, also not on this hypervisor.
|
||||
|
||||
@@ -54,4 +54,4 @@ The snapshot captures host/hardware/filesystem/network/ports but **not** VM-leve
|
||||
|
||||
## Placement rule
|
||||
|
||||
This is a hypervisor, not a target for Docker stacks. Add new workloads by standing up VMs here (or on ana-docker / ana-ml2, whichever fits) rather than deploying containers directly on the PVE host.
|
||||
This is a hypervisor, not a target for Docker stacks. Add new workloads by standing up VMs here (or on ana-docker / fv-ml1, whichever fits) rather than deploying containers directly on the PVE host.
|
||||
|
||||
Reference in New Issue
Block a user