dohertj2
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>