Files
network/CLAUDE.md
T
dohertj2 14cc4faa28 Delete the Plex VM disks
Completes section 9 step 3. govc vm.destroy Plex removed the inventory
entry and the [NVME_1] Plex/ folder; datastore free space went
1,619.8 -> 1,756.1 GB (+136.3 GB). 10.100.0.24 / 10.50.0.31 and MACs
00:0c:29:4a:ef:3d / 00:0c:29:4a:ef:47 are now free for reuse.

Done on 2026-09-17 rather than the planned ~2026-10-15. Checking the
plan's own Veeam precondition inverted its assumption: the Backup VMs
job has EnableDeletedVmDataRetention set to False with Simple retention
of 7 restore points, so a VM removed from the job has its points pruned
as the remaining VMs roll the chain - Plex's are due to age out around
2026-09-24, about three weeks before the disks were scheduled for
deletion. Deleting while a good restore point still existed (2026-09-17
03:01, consistent) was safer than deleting later with none.

Recovery position is now: Veeam image restore until ~2026-09-24, then
only the pre-migration library DB at
/mnt/share/backups/plex-migration-2026-09-16/, which rebuilds a Plex
install but not the VM.

veeam.md gains the retention gotcha, since it applies to any future
decommission and the 30-day DeletedVmsDataRetentionPeriodDays value is
misleading while the toggle is off.

Also flags in esxi.md that its VM tables are incomplete: the host has 10
VMs, WW_DEV_VM / Rockwell_Win10 / TCBSD are absent, and DevVM is powered
off rather than on. Left the tables themselves alone as out of scope.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-17 12:12:20 -04:00

2.0 KiB

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Project Purpose

netfix is a diagnostic/debugging toolkit for troubleshooting network connectivity between VMs running on an ESXi hypervisor host and an external client, connected through Unifi network switches.

Environment Context

  • Hypervisor: VMware ESXi
  • Network infrastructure: Ubiquiti Unifi switches
  • Debugging scope: VM-to-external-client connectivity issues across the ESXi virtual switch and physical Unifi switch layers

Credentials

Credentials live inline in each component's .md file under its Access section. Read the relevant doc to find them.

Components

  • TrueNAS Server — NAS at 10.100.0.25 (management) / 10.50.0.x (storage), serves SMB and NFS
  • ESXi Host — HP server at 10.2.0.12, ESXi 8.0.3, 10 VMs (6 powered on), access via govc only (not SSH). Read esxi.md for credentials and connection details.
  • Docker Server — Debian 13 at 10.100.0.35, Docker host for 21 containers (arr stack, Traefik, Semaphore/Ansible). This is the local machine.
  • Plex Server — container on the Docker host (10.100.0.35) since 2026-09-16, Plex Media Server 1.43, NFS media from TrueNAS. Old Debian 11 VM decommissioned and deleted 2026-09-17.
  • Home Assistant — HAOS at 10.100.0.40, HA 2026.2.2, 2,411 entities, smart home automation. API access only (no SSH).
  • Ignition Gateway — Debian 11 at 10.100.0.90, Ignition 8.3.3 (Maker), SCADA/IIoT platform with PostgreSQL 13
  • Veeam Server — Windows Server 2025 at 10.100.0.30, Veeam B&R 12.3, backup server. Read veeam.md for credentials and connection details.
  • Desktop — Windows PC, dual-homed on LAN_100 (10.100.0.49) and DATA_50 (10.50.0.49)
  • Wonderware Dev VM — Windows 10 ESXi VM at 10.100.0.48, OpenSSH (passwordless)
  • Unifi Network — UDM Pro gateway + USW Pro Aggregation central switch, API access via key