Galaxy inventory
The five Proxmox nodes, the 18 guests and three templates on the Galaxy cluster, with what each one runs, as read back from the live cluster on 2026-09-24.
Galaxy is my five-node Proxmox VE cluster. This page is the current inventory: the physical nodes, every guest and template, and what each one is for. I read the figures back from pvesh get /cluster/resources and the guest configuration files on 2026-09-24, and the service versions from the running services on 2026-09-24 and 2026-09-25. Two later changes are folded in: the ubuntu-dev disk expansion on 2026-09-28 and the Sure deployment on 2026-10-05.
Note: The repo keeps this state in four living files: Galaxy Inventory, VMs, LXCs and Services. The ten dated inventory sets that came before them moved to the archive on 2026-09-25 and nothing is added to them.
At a glance
| Item | Value (2026-09-24) |
|---|---|
| Nodes | 5, all on pve-manager/9.2.11, quorum 5 of 5 votes |
| Compute | 30 physical cores, 38 hardware threads, 114.78 GiB of usable memory |
| Guests | 18: 12 QEMU VMs and 6 LXCs, plus 3 templates |
| Running | 16; kali-pen and HQ-WS001 were stopped |
| High availability | None. ha-manager config returns nothing |
| Shared storage | None. Every guest lives on its own node’s disks |
| Empty node | green-server, which has unresolved host memory errors from 2026-09-20 |
| Monitoring | Prometheus scraped 57 targets in 7 jobs, all up; the Wazuh manager listed 15 active remote agents |
On 2026-09-24 four nodes ran kernel 7.0.14-8-pve and blue-server ran 7.0.14-15-pve, which all five had installed at the 2026-09-06 reading.
Nodes
| Node | Hardware | CPU (cores / threads) | Memory (usable, used on 2026-09-24) | Storage | What runs there |
|---|---|---|---|---|---|
grey-server | MSI MS-7C91 board, NVIDIA GeForce GTX 1080 Ti | AMD Ryzen 7 3700X (8 / 16) | 64 GB installed, 62.72 GiB usable, 51.61 GiB used | 1 TB NVMe (boot and local-lvm), 2 TB SATA SSD (ssd-lvm1), 2 TB HDD (hddpool-1, ZFS) | 10 guests and all 3 templates: the identity plane, the security stack, the development workstations and docker-main |
purple-server | Lenovo 10RRS0LN00 | Intel Core i5-8500T (6 / 6) | 16 GB installed, 15.46 GiB usable, 11.68 GiB used | 256 GB NVMe (boot and local-lvm), 250 GB SATA SSD (ssd-lvm2, empty) | app-01, edge-01, alpha-prod-01 |
blue-server | Lenovo 10MUS08B00 | Intel Core i5-7500T (4 / 4) | 6 GB installed, 5.68 GiB usable, 2.99 GiB used | 256 GB NVMe (boot and local-lvm), 500 GB HDD (unused) | ansible-01, monitor-01, docker-network, docker-blue |
red-server | Lenovo 10RRS0LN00 | Intel Core i5-8500T (6 / 6) | 16 GB installed, 15.46 GiB usable, 3.29 GiB used | 256 GB NVMe (boot and local-lvm), 1 TB HDD (media data) | media-01 |
green-server | Lenovo 10RRS0LN00 | Intel Core i5-8500T (6 / 6) | 16 GB installed, 15.46 GiB usable, 1.91 GiB used | 256 GB NVMe (boot and an empty local-lvm), 320 GB HDD (failed, not used) | Nothing. It holds no guests until a full memory test passes |
grey-server, blue-server and red-server draw power from UPS-02; the records do not report a UPS for the other two. The four Lenovo nodes use their integrated Intel graphics, and Red’s UHD Graphics 630 is the render device media-01 passes through for Jellyfin Quick Sync.
A few hardware facts the table cannot hold:
- Purple’s boot drive was replaced on 2026-07-25. The Samsung NVMe it shipped with wore out at 169% of its rated write endurance, so I cloned it onto a Toshiba THNSF5256GPUK and added the 850 EVO on SATA at the same time.
- Blue’s 500 GB HDD passed a full extended SMART read on 2026-07-31 and is blank. It is available if I want to assign it.
- Green’s 320 GB HDD failed its extended test at 60 percent with a read failure and two pending sectors. It stays installed only as failed hardware, with no partition, filesystem or Proxmox storage on it.
- Green’s memory failed an online test on 2026-09-20 with 25 failure lines, and a locked 8 GiB test failed again six seconds after launch on 2026-09-27. Isolating the bad module or slot needs physical access.
Cluster storage
local and local-lvm exist on every node. The other three storages are restricted to one node each, so pvesm status reports them disabled when you ask any other node. That is how ssd-lvm2 was once recorded as disabled when it never was.
| Node | Storage | Type | Total | Used % (2026-09-24) |
|---|---|---|---|---|
grey-server | hddpool-1 | zfspool | 1,798.5 GiB | 70.7% |
grey-server | ssd-lvm1 | lvmthin | 1,830.9 GiB | 11.0% |
grey-server | local-lvm | lvmthin | 793.8 GiB | 30.3% |
purple-server | local-lvm | lvmthin | 140.9 GiB | 28.4% |
purple-server | ssd-lvm2 | lvmthin | 228.1 GiB | 0.0% |
blue-server | local-lvm | lvmthin | 141.2 GiB | 39.0% |
red-server | local-lvm | lvmthin | 141.2 GiB | 31.9% |
green-server | local-lvm | lvmthin | 141.2 GiB | 0.0% |
After the 2026-09-28 expansion of ubuntu-dev, Grey’s local-lvm stood at 32.12%. Purple’s thin volumes are provisioned at 154.01 GiB against a 140.87 GiB pool, so any new allocation there needs a capacity check first.
Warning:
hddpool-1read 82.46% on 2026-09-06 and 70.7% on 2026-09-24. No record explains the roughly 200 GiB it gave back, and finding it is an open item in the Galaxy backlog.
Virtual machines
| VMID | Name | Node | State | OS | vCPU | Memory | Disk | VLAN | Purpose |
|---|---|---|---|---|---|---|---|---|---|
| 102 | kali-pen | grey-server | stopped | Kali Linux 2026.2 | 6 | 8 GiB | 100G | 40 | Penetration-testing VM, rebuilt on 2026-08-26 under a new VMID |
| 103 | win11-dev | grey-server | running | Windows 11 Pro 25H2 | 4 | 8 GiB | 120G | 40 | Standalone Windows development workstation with Secure Boot and TPM 2.0; activation still open |
| 105 | ubuntu-dev | grey-server | running | Ubuntu 26.04.1 LTS, GNOME 50 | 6 | 12 GiB | 230G | 40 | My development workstation and a Docker host; also the Samba file server for my own machines |
| 109 | splunk-siem | grey-server | running | Rocky Linux 10.2 | 6 | 12 GiB | 150G | 72 | SIEM: Splunk Enterprise 10.4.0, Enterprise Security 8.5.1 and SC4S for UniFi CEF |
| 116 | app-01 | purple-server | running | Debian 13 (trixie) | 4 | 8 GiB max, 4 GiB min | 64G | 80 | App platform: Coolify 4.3.23 with its Traefik 3.7.12 proxy |
| 121 | edge-01 | purple-server | running | Debian 13 (trixie) | 2 | 4 GiB max, 2 GiB min | 30G | 30 | Edge host for the public services |
| 200 | security-01 | grey-server | running | Ubuntu 24.04.4 LTS | 4 | 10 GiB max, 8 GiB min | 100G | 72 | Wazuh 4.14.8 manager, indexer and dashboard |
| 301 | HQ-DC01 | grey-server | running | Windows Server 2025 Standard | 4 | 4 GiB | 80G | 65 | First domain controller: all five operations master roles, global catalog, AD-integrated DNS |
| 302 | HQ-DC02 | grey-server | running | Windows Server 2025 Standard | 4 | 4 GiB | 80G | 65 | Second domain controller: global catalog and AD-integrated DNS |
| 303 | HQ-MGT01 | grey-server | running | Windows Server 2025 Standard | 2 | 6 GiB | 100G | 65 | Management and hybrid identity: Windows Admin Center, Entra provisioning agent, Azure Arc agent |
| 310 | HQ-WS001 | grey-server | stopped | Windows 11 Pro 25H2 | 4 | 8 GiB | 80G | 65 | Domain-joined test workstation for tiered policy and Windows LAPS |
| 401 | alpha-prod-01 | purple-server | running | Debian 13 (trixie) | 6 | 4 GiB max, 2 GiB min | 60G | 80 | Voice services: two TeamSpeak 3 Server 3.13.8 instances, TS3 Manager and a reachability collector |
Every VM uses OVMF firmware, the virtio-scsi-single controller and the QEMU guest agent. All five Windows VMs carry TPM 2.0. None is an HA resource.
LXC containers
All six containers are unprivileged and were running on 2026-09-24. Together they hold 13 vCPUs, 27 GiB of memory and 8.5 GiB of swap.
| CTID | Name | Node | OS | vCPU | Memory | Root disk | VLAN | Purpose |
|---|---|---|---|---|---|---|---|---|
| 100 | ansible-01 | blue-server | Debian 13 (trixie) | 1 | 1 GiB | 16G | 40 | Automation and node provisioning: Ansible 14.2.0, Semaphore 2.18.27, the Galaxy PXE service and TFTP |
| 104 | monitor-01 | blue-server | Debian 13 (trixie) | 2 | 2 GiB | 20G | 73 | Monitoring: Prometheus 3.14.0, Grafana 13.2.2, the exporters, the Discord alert bot and PeaNUT 6.0.0 |
| 107 | docker-network | blue-server | Debian 13 (trixie) | 2 | 2 GiB | 32G | 85 | Network access: Nginx Proxy Manager 2.15.1 and NetBird 0.79.0 |
| 108 | docker-blue | blue-server | Debian 13 (trixie) | 2 | 2 GiB | 15G | 40 | Remote access and integrations: RustDesk 1.1.16 and the MeshCentral 1.2.6 pilot |
| 110 | docker-main | grey-server | Debian 12 (bookworm) | 4 | 16 GiB | 100G, plus 2,900G /data on hddpool-1 | 40 | Docker apps, with the GTX 1080 Ti passed through: Immich, Forgejo, BookOrbit, Homarr, Sure, Dockhand, Ollama, Open WebUI, App Portal, CLI Proxy API |
| 842 | media-01 | red-server | Debian 13 (trixie) | 2 | 4 GiB | 100G, plus 916G usable on the HDD bind mount | 40 | Media: Jellyfin 12.1.0, Seerr, Sonarr, Radarr, Prowlarr, FlareSolverr and qBittorrent behind Gluetun and Proton VPN |
A few details worth knowing:
docker-networkanddocker-blueare no longer HA resources. After the 2026-07-20 stranding incident I pinned both toblue-serverwith a strict node-affinity rule. Both resources and the rule were present on 2026-09-06 and gone by 2026-09-23, with no record of the removal. A Blue outage now stops both until Blue returns.media-01refuses to start without its HDD. Thedatadirectory exists only on the ext4 filesystem the host automounts, so the stack fails closed instead of writing media onto its root volume. It also gets Red’s render device for Jellyfin Quick Sync and/dev/net/tunfor the Gluetun WireGuard tunnel.docker-mainsits outside the standard account model. It is root-login only, keyed, and is the one guest still on Debian 12.- Nineteen containers ran on
docker-mainon 2026-10-05 after Sure added four. The internal documentation site there has been stopped since 2026-09-22.
Templates
| VMID | Name | OS | vCPU | Memory | Disk | VLAN | Notes |
|---|---|---|---|---|---|---|---|
| 101 | debian13-template | Debian 13 | 4 | 4 GiB | 60G | 40 | Base for new Debian guests |
| 300 | ws2025-template | Windows Server 2025 Standard | 4 | 4 GiB | 80G | 65 | Built 2026-09-08 as the source for the three Windows Server guests; QEMU agent, OpenSSH and virtio drivers, sysprepped |
| 9000 | ubuntu-cloud-template | Ubuntu 24.04.4 LTS | 2 | 2 GiB | 20G | 80 | Cloud-init template |
All three live on grey-server in ssd-lvm1.
Warning: Sysprep does not regenerate SSH host keys, so every clone of
ws2025-templatepresents the template’s host key fingerprint until the keys underC:\ProgramData\sshare deleted andsshdrestarts. Any guest cloned from the Debian or Ubuntu template also arrives with root locked, which matters because the sudo policy on the fleet points the sudo prompt at root’s password. The account play has to run on a new host before the sudo play does.
Workload placement in one view
grey-server HQ-DC01 HQ-DC02 HQ-MGT01 HQ-WS001 (stopped)
splunk-siem security-01
win11-dev ubuntu-dev kali-pen (stopped)
docker-main (CT 110)
templates 101, 300, 9000
purple-server app-01 edge-01 alpha-prod-01
blue-server ansible-01 monitor-01 docker-network docker-blue
red-server media-01
green-server (empty)
Most of that placement is recent. Between 2026-09-11 and 2026-09-12 I moved app-01, edge-01 and alpha-prod-01 from Grey to Purple’s NVMe and ansible-01 from Grey to Blue. On 2026-09-23 win11-dev moved from Green to Grey after Green’s memory test failures. The change history has each move.
Monitoring and agent coverage
- Prometheus covers every running Linux guest with
node_exporterand the Docker hosts with cAdvisor. All five nodes export node metrics, and UPS-02 ongrey-serverreports through NUT. UPS-01 has had no data path since its cable was disconnected on 2026-08-28. - Wazuh listed 15 active remote agents on 2026-09-24: the five Proxmox nodes and ten Linux guests.
splunk-siemand the Windows guests run no agent. - Dockhand manages
docker-mainthrough its local socket and six more Docker hosts through Hawser agents.app-01has no Hawser agent, so Coolify’s containers stay outside Dockhand.
Retired guests
Retired guests stay in the inventory files as a list, and their full records move to the archive. The retired guests page summarizes them.
| ID | Name | Removed |
|---|---|---|
| CT 104 | ai-alpha-01 (OpenClaw) | Already gone when checked on 2026-07-25 |
| VM 111 | fedora-dev | Confirmed absent on 2026-08-08 |
| CT 105 | ai-bravo-02 (TNIO AI Bot) | Deleted with its root volume on 2026-08-09 |
| VM 102 | debian-dev | Destroyed 2026-08-14 after ubuntu-dev replaced it |
| VM 122 | kasm-01 | Destroyed with all volumes on 2026-08-19 |
| VM 117 | supabase-01 | Confirmed deleted on 2026-08-20 |
| VM 106 | kali-pen (first build) | Destroyed 2026-08-26 and rebuilt as VM 102 |
| CT 123 | game-01 | Deleted with its game data on 2026-09-12 |
VMIDs get reused. VM 102 was debian-dev until 2026-08-14 and has been kali-pen since 2026-08-26, and CT 104 was ai-alpha-01 before it was monitor-01.