14cc4faa28
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>
31 lines
2.0 KiB
Markdown
31 lines
2.0 KiB
Markdown
# 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](truenas.md) — NAS at 10.100.0.25 (management) / 10.50.0.x (storage), serves SMB and NFS
|
|
- [ESXi Host](esxi.md) — 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](docker.md) — Debian 13 at 10.100.0.35, Docker host for 21 containers (arr stack, Traefik, Semaphore/Ansible). **This is the local machine.**
|
|
- [Plex Server](plex.md) — **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](ha.md) — HAOS at 10.100.0.40, HA 2026.2.2, 2,411 entities, smart home automation. API access only (no SSH).
|
|
- [Ignition Gateway](ignition.md) — Debian 11 at 10.100.0.90, Ignition 8.3.3 (Maker), SCADA/IIoT platform with PostgreSQL 13
|
|
- [Veeam Server](veeam.md) — Windows Server 2025 at 10.100.0.30, Veeam B&R 12.3, backup server. **Read veeam.md for credentials and connection details.**
|
|
- [Desktop](desktop.md) — Windows PC, dual-homed on LAN_100 (10.100.0.49) and DATA_50 (10.50.0.49)
|
|
- [Wonderware Dev VM](ww.md) — Windows 10 ESXi VM at 10.100.0.48, OpenSSH (passwordless)
|
|
- [Unifi Network](unifi.md) — UDM Pro gateway + USW Pro Aggregation central switch, API access via key
|