Retired guests

These are the guests whose records moved to the archive when I removed them from Galaxy. The live inventory keeps a one-line entry for each; this page holds what the archived guest records and change records say. Guests with a retired system of their own get a short section here and a link to that system’s page.

Guest	ID	Node	Role	Removed
ai-alpha-01	CT 104	grey-server	A Discord chat assistant	Found already gone on 2026-07-25
ai-bravo-02	CT 105	grey-server	The TNIO AI bot	Archived 2026-07-25, deleted 2026-08-09
debian-dev	VM 102	grey-server	GNOME development workstation	Destroyed 2026-08-14
kasm-01	VM 122	purple-server	Kasm Workspaces	Destroyed 2026-08-19
supabase-01	VM 117	grey-server	Not recorded	Found already deleted on 2026-08-20
game-01	CT 123	green-server	Pelican Panel and Minecraft	Destroyed 2026-09-12

Proxmox reuses guest IDs, so these numbers have new owners: CT 104 is now monitor-01, CT 105’s ID went to the VM ubuntu-dev, and VM 102 has been kali-pen since 2026-08-26.

ai-alpha-01

CT 104 was a Debian container on grey-server that ran a Discord chat assistant.

Setting	Recorded value
Size	2 vCPU, 4 GiB memory, 2 GiB swap
Disk	A 40 GiB root volume on ssd-lvm1
Network	Personal-A, VLAN 40, with nesting enabled

When I queried the cluster on 2026-07-25, no guest with ID 104 or that hostname existed on any of the four nodes, and SSH to it had already timed out in the 2026-07-14 automation checks. It had been deleted before then; the exact date wasn’t retained, and neither was the reason. On 2026-07-25 I preserved its last recorded configuration and removed it from the Ansible inventories, the controller’s identity allowlist and my local SSH state.

ai-bravo-02

CT 105 ran the TNIO AI bot, a Discord lore bot.

Setting	Recorded value
OS	Ubuntu, unprivileged, with nesting, keyctl and FUSE
Size	6 vCPU, 23.81 GiB memory, 8 GiB swap
Disk	A 100 GiB root volume on ssd-lvm1
Devices	Seven NVIDIA device nodes, for the GPU
Network	Personal-A, VLAN 40

Archival, 2026-07-25. Proxmox reported the guest stopped. I changed its autostart from on to off, because a reboot of grey-server would otherwise have started an archived guest before its deletion date, and confirmed it stayed stopped. I moved the 50-file project tree, its walkthrough and its diagrams into Archive/, copied the guest’s configuration, storage, device and network tables into an archived guest record, removed it from the Ansible inventory, the SSH identity targets and my local SSH state, and scheduled deletion for 2026-08-15. I left the guest and its disk in place until then.

Retirement, 2026-08-09. I closed the deletion checklist six days early. The guest was still stopped with autostart off, and nothing in UniFi, Ansible, monitoring, Wazuh or my SSH configuration depended on it. I guarded the destroy on all three expected conditions, stopped, autostart off and the exact root volume, then deleted CT 105 with its 100 GiB volume. ssd-lvm1 allocation fell from 15.72 to 13.05 percent and Galaxy stayed quorate with five votes. A residue sweep on 2026-08-20 removed its task logs from Grey and moved the dedicated records into the archive. The records give no reason for shelving the bot beyond the guest already being stopped.

debian-dev

VM 102 was my development workstation: a GNOME desktop, a database test VM and a Docker host, all in one.

Setting	Final recorded value
OS	Debian GNU/Linux 13.6 with GNOME Shell 48.7
CPU	6 vCPU, CPU type host
Memory	16 GiB maximum, 12 GiB minimum, with ballooning
Disk	120 GiB on ssd-lvm1, with discard, an I/O thread and SSD emulation, plus a 4 MiB EFI disk
Firmware	OVMF on q35, virtio-scsi-single, a QXL display
Network	Personal-A, VLAN 40

On 2026-07-15 it was much smaller, at 4 vCPU, 4 GiB of memory and a 60 GiB disk.

GNOME, 2026-07-15

I installed the newest GNOME that Debian 13 stable offered, through the complete task-gnome-desktop task rather than just the shell, and stayed on Debian’s own packages rather than mixing in unstable or third-party repositories. Removing a whole desktop task isn’t a clean inverse operation, so I took a Proxmox snapshot first as a rollback point. The result was GNOME Shell 48.7 with GDM 48.0, booting to graphical.target. I held the reboot until I could watch it, and the controlled reboot proved that SSH, GDM and the Wayland greeter all came back on their own.

Two follow-ups made it pleasant to use:

• The network indicator. GNOME showed a question mark on the wired connection, because the interface still belonged to the old ifupdown and dhcpcd setup. I moved it to a native NetworkManager profile with the same static address, gateway and DNS, and proved that a NetworkManager restart reconnected it on its own. I also disabled the connectivity probe, because Debian’s packaged probe address didn’t resolve from this network.
• Authentication prompts. A Polkit rule granted my account every Polkit action without a prompt, but only from the active local GNOME session. The same action stayed denied from a remote SSH shell.

Baseline and toolchains, 2026-08-08

VM 102 had become the machine I developed on when I deleted fedora-dev, and it had never been brought up to the Linux host baseline; the 2026-08-05 fleet sweep had found it unreachable. On 2026-08-08 I fixed that:

• Access. The passwordless sudo rule moved from the main sudoers file into a validated drop-in. A hardening drop-in for SSH disabled root login, passwords, keyboard-interactive login and X11 forwarding and allowed a single user. Root was locked, and I proved key-only access from a third machine rather than from the session making the change.
• Fleet services. It got a Wazuh agent pinned at 4.14.6-1 to match the fleet, because an agent must never lead its manager, in a new workstation group, as agent 019. It got node_exporter and a destination in the monitoring firewall policy, which took Prometheus to 52 of 52 targets up, and unattended-upgrades with the 20auto-upgrades file the package doesn’t create, without which the service is enabled but never runs.
• Toolchains. Two Node runtimes had been installed, and which one answered depended on the kind of shell: my terminal got nvm’s 24.19.0 while non-interactive SSH sessions got apt’s 20.19.2, so a build could pass in one and fail in the other. I replaced both with one system-wide Node 24.19.0, installed Go 1.26.5 after checking its published SHA-256, put Go tools and Python linters in /usr/local/bin so every shell found them, and added VS Code 1.132.0 and Neovim 0.12.4 with LazyVim.

An audit afterwards found one problem I had caused. The node_exporter install had pulled in a recommended collectors package the project deliberately leaves out, and with it openipmi.service, which failed at every boot on a VM with no BMC. I purged the package and its dependencies, then fixed the cause: the playbook’s apt task now sets install_recommends: false, and a rerun reported no change.

Decommission, 2026-08-14

ubuntu-dev (VM 105) took over as the machine I develop on when the last service moved across on 2026-08-13. The firewall entries, UniFi client and DNS record and the Prometheus target had already been repointed to it then, so debian-dev sat idle.

On 2026-08-14 I shut it down cleanly over ACPI rather than forcing it off, confirmed it was stopped, and destroyed it with --purge. Both volumes went, ssd-lvm1 got its 120 GiB back, and the cluster no longer listed VM 102. I deregistered Wazuh agent 019, which reported Disconnected and would otherwise have sat in the manager’s list indefinitely. The GNOME, baseline and two troubleshooting records moved to the archive rather than being deleted, because they still describe useful work.

kasm-01

VM 122 ran Kasm Workspaces on purple-server, at 6 vCPU, 12 GiB of memory and a 200 GiB disk on the ssd-lvm2 thin pool. I destroyed it with all its volumes on 2026-08-19. Its page covers the build, the incident and the decommission.

supabase-01

VM 117 was a Debian 13 guest on grey-server.

Setting	Recorded value
Size	4 vCPU, 12.60 GiB memory
Disk	100 GiB on ssd-lvm1, plus a 4 MiB EFI disk
Firmware	OVMF
Network	SERVERS-A, VLAN 80

The archived records give its name and size but not what ran on it. It was already unreachable over SSH in the 2026-07-14 and 2026-07-28 checks, and its Prometheus target had been removed as unavailable during the July network work.

When I checked on 2026-08-20, VM 117 was already gone: no configuration file, no cluster resource and no volume. I had deleted it deliberately at some earlier point, but I kept no record of when or with which command, so the retirement record doesn’t claim either. That day I removed what was left. Each of the five nodes still held a historical metric file for VMID 117, which I deleted only after guarding on the configuration and the cluster resource being absent. I also removed its task logs from Grey, its entries in the SSH inventory and the deployed automation projects, its card on the architecture diagram, and its page on my internal documentation site. Prometheus, Nginx Proxy Manager and Wazuh held nothing for it.

game-01

CT 123 ran the game servers on green-server, at 6 vCPU, 12 GiB of memory, 2 GiB of swap and an 80 GiB root volume on local-lvm. I built it on 2026-08-07, retired it on 2026-09-12 and destroyed it the same day with Pelican and both Minecraft worlds, which left Green’s local-lvm at 0.00 percent used.

The Green node rename

The archive also holds a cancelled plan to replace each node with a *-node name, and a preflight snapshot of green-server taken on 2026-07-31 for its pilot. No guest or node was removed. The Proxmox cluster page covers why I cancelled it and kept the existing names.