dohertj2/network
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Delete the Plex VM disks

Browse Source 
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>
This commit is contained in:
dohertj2
2026-09-17 12:12:20 -04:00
parent 5a4da57457
commit 14cc4faa28
5 changed files with 33 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plex-docker-migration.md
+23 -4
View File
@@ -1,6 +1,6 @@
# Plex Migration: ESXi VM → Docker Container
**Status: EXECUTED 2026-09-16. DECOMMISSIONED 2026-09-17.** Decisions 1 & 2 ratified as Option A / Option A. Cutover completed with ~22 min of Plex downtime (transfer itself 5m38s). All verification in §8 passed except the two items needing a real client, noted there. §9 decommission steps 1, 2 and 4-7 are **done** (see the log at the end of §9); step 3 — deleting the VMDKs — is deliberately **deferred to ~2026-10-15**.
**Status: EXECUTED 2026-09-16. DECOMMISSIONED 2026-09-17.** Decisions 1 & 2 ratified as Option A / Option A. Cutover completed with ~22 min of Plex downtime (transfer itself 5m38s). All verification in §8 passed except the two items needing a real client, noted there. §9 decommission is **complete** — all steps including 3 (VMDK deletion) were done on 2026-09-17. See the log at the end of §9.
**Created:** 2026-09-16
**Source:** `plex` VM, 10.100.0.24, Debian 11 (EOL)
**Target:** `DOCKER` host, 10.100.0.35, Debian 13, containerised + Ansible-managed
@@ -555,7 +555,7 @@ the Traefik file-provider service and the UDM `PLEX` port-forward all resolve to
|---|---|---|
| 1 | Veeam `Backup VMs` | Plex removed via `Remove-VBRJobObject`. **Veeam converts a removed include into an explicit `Exclude` rather than deleting the entry** — re-running the removal leaves it as `Exclude`. That is the same shape as the pre-existing `Deployarr` exclusion and is the expected end state, not a failure. |
| 2 | Power off + snapshot | Guest shut down gracefully via `govc vm.power -s Plex` (VMware Tools `toolsOk`); confirmed `plexmediaserver` was still `inactive`/`disabled` first. Snapshot `pre-docker-migration 2026-09-16` then removed **while powered off** — safer consolidation than the plan's on-line ordering. Disk collapsed `Plex-000001.vmdk` → `Plex.vmdk`, `runtime.consolidationNeeded = false`. |
| 3 | Delete VMDKs | **Deferred to ~2026-10-15**, per plan. |
| 3 | Delete VMDKs | **Done 2026-09-17**, ahead of the planned ~2026-10-15 — see "Early deletion" below. `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). |
| 4 | Guacamole "Plex SSH" | Deleted via the Guacamole API (connection id 3, `HTTP 204`). **The `guacamole` role is create-only** (`when: item.name not in guac_existing_names`), so it cannot remove a connection — the entry was also deleted from `roles/guacamole/defaults/main.yml` so a rebuild does not recreate it. |
| 5 | Addresses | Neither MAC had a Unifi fixed reservation, so `.24`/`10.50.0.31` were plain leases; both clients (`00:0c:29:4a:ef:3d`, `00:0c:29:4a:ef:47`) were forgotten via `cmd/stamgr`. |
| 6 | Docs | [plex.md](plex.md), [CLAUDE.md](CLAUDE.md), [esxi.md](esxi.md), [veeam.md](veeam.md). `docker.md` already listed `plex`. ESXi port-group counts corrected LAN_100 7→6 and DATA_50 4→3, verified by counting NICs on powered-on VMs. |
@@ -569,8 +569,27 @@ the Traefik file-provider service and the UDM `PLEX` port-forward all resolve to
> `unknown tokenizer: collating`. That is the stock binary lacking Plex's custom collation on the FTS virtual tables, **not**
> corruption — use `Plex SQLite` for a real whole-DB check. Ordinary table queries work fine with stock `sqlite3`.
**Before deleting the VMDKs**, confirm no Veeam restore point is still needed, then:
`govc vm.destroy Plex` (removes the VM and its `[NVME_1] Plex/` folder).
### Early deletion of the VMDKs — 2026-09-17
The disks were destroyed the same day rather than at the planned ~2026-10-15. Checking the Veeam precondition first turned
up something that inverted the plan's assumption and is worth recording:
- A **consistent, uncorrupted restore point exists at 2026-09-17 03:01**, captured after the cutover and before Plex was
removed from the job that morning. The chain runs 2026-09-05 → 2026-09-17 with a Full on 2026-09-12.
- But the `Backup VMs` job has **`EnableDeletedVmDataRetention: False`** with Simple retention of 7 restore points. A VM
removed from the job stops generating points, so its data is pruned as the remaining VMs roll the chain — Plex's points
are expected to disappear around **2026-09-24**.
So the plan's "keep the disks until mid-October as the rollback" was resting on a Veeam safety net that expires roughly
three weeks *earlier* than the disks were due to be deleted. Deleting on 2026-09-17, while a good restore point still
existed, was strictly safer than deleting on 2026-10-15 with none.
**Current recovery position:** no VM to restore. Until ~2026-09-24 a Veeam image restore is possible; after that the only
artifact is the pre-migration library DB at `/mnt/share/backups/plex-migration-2026-09-16/`, which rebuilds a Plex install
(libraries, watch history, `MachineIdentifier` via `Preferences.xml`) but not the VM.
**If a longer-lived VM-level copy is ever wanted for another decommission**, export the restore point to a standalone full
backup *before* removing the VM from its job — job retention does not protect it otherwise.
---