oikos/hosts/strong.md

strong — Proxmox host

Second node in the Homelab cluster, alongside hubris. Formerly a Linux dev workstation nicknamed "ludo" (or "ludo-mini") — reformatted to Proxmox VE on 2026-07-01. No LXCs/VMs deployed on it yet.

At a glance

• Role: Proxmox VE 9.2.3 cluster member (kernel 7.0.12-1-pve)
• Naming: the OS/cluster hostname is strong (leftover from install, kept as-is). This wiki page and inventory.yaml also use strong as of 2026-07-01 — earlier the same day the inventory entry was briefly named ludo-mini, but that was renamed so the hostname bootstrap needs (hosts/$(hostname).yaml) would just resolve. "Ludo"/"ludo-mini" remains the machine's everyday nickname; some older docs (investigations, the library-SSD migration plan) still refer to it that way — that's fine, those are historical.
• Hardware: AMD Ryzen 7 PRO 6850U, 16 threads, 28 GiB RAM.
  • nvme0n1 — MasonSemi MC3100 1TB (boot/OS): pve-root 96G, pve-data (thinpool) 815G, 8G swap.
  • nvme1n1 — WD_BLACK SN7100 2TB, added 2026-07-01. Arrived with an existing APFS partition (previously used in a Mac) — wiped via pvesh set nodes/strong/disks/wipedisk --disk /dev/nvme1n1, then turned into its own LVM-thin pool via pvesh create nodes/strong/disks/lvmthin (handles pvcreate/vgcreate/lvcreate + storage.cfg registration in one step). Registered as Proxmox storage ludo-lvm (VG ludo-lvm, thinpool ludo-lvm, ~1.8 TiB usable — kept the ludo-lvm name since that's what was actually created live; not worth renaming), restricted nodes strong in /etc/pve/storage.cfg — same pattern as hubris's library pool. Empty so far; this is separate from the library-SSD migration plan's planned drive move from hubris (that hasn't happened) — this is general-purpose VM/CT capacity.
• Network: vmbr0 is bridged straight onto the household LAN — 192.168.178.181/24, gateway 192.168.178.1. Unlike hubris, there is no internal/uplink bridge split yet — vmbr0 here plays the role hubris's vmbr1 plays there. Reachable from the homelab subnet (192.168.8.0/24) via the existing Fritz!Box static route through hubris; no new cabling or routing was needed to join the cluster.
• Storage: local + local-lvm (cluster-wide default names, shared with hubris by convention, actually separate per-node volumes). Hubris's library lvmthin pool is restricted to nodes hubris in /etc/pve/storage.cfg and does not exist here.
• Mesh: Netbird not installed — fresh OS wiped whatever the old workstation had. Reachable today only via LAN routing (confirmed DNS for *.hubris.network already resolves correctly here via 192.168.8.2). Add to Netbird if off-LAN access to this host itself (distinct from any future guests) is needed.
• Homelab-context client enrollment: not done yet — no /opt/homelab-context, no age key, no homelab CLI. Separate from the Proxmox cluster join. See agent-enrollment.md.

Cluster membership

Joined hubris's single-node cluster (Homelab) via pvecm add on 2026-07-01. See hosts/hubris.md#cluster for the full cluster picture, node IDs, and the quorum tradeoff (2 nodes, no QDevice — either node going down freezes management on the survivor).

SSH

Root login via the same key set trusted on hubris (root@hubris, d.toro.v@pm.me) — installed 2026-07-01 by appending to /root/.ssh/authorized_keys (now symlinked to /etc/pve/priv/authorized_keys post cluster-join, so it's cluster-synced same as hubris). No password auth needed going forward.

Related

• hubris — Proxmox host
• Library SSD migration plan — the larger project this is Phase 1 of (filename kept as-is, historical)
• Network
• SSH access
• Agent enrollment

Changelog

2026-07-01 — inventory identity renamed ludo-mini → strong

Discovered while starting client enrollment: bootstrap.sh looks up hosts/$(hostname).yaml, and the OS hostname here is strong, not ludo-mini. Renaming the OS hostname was ruled out (already a cluster member — Proxmox doesn't support in-place node rename, only leave+rejoin). Renamed the wiki/inventory side instead: inventory.yaml key, this page (hosts/ludo-mini.md → hosts/strong.md), README, ssh-access.md all now say strong. "Ludo"/"ludo-mini" is still fine as a spoken nickname.

2026-07-01 — 2nd NVMe added; new LVM-thin pool ludo-lvm

User added a WD_BLACK SN7100 2TB (nvme1n1), previously used in a Mac (arrived with an EFI + APFS partition table — confirmed disposable, wiped). Used Proxmox's own disk-management API rather than raw LVM commands: pvesh set nodes/strong/disks/wipedisk --disk /dev/nvme1n1 to clear the old partition table/signatures, then pvesh create nodes/strong/disks/lvmthin --name ludo-lvm --device /dev/disk/by-id/nvme-WD_BLACK_SN7100_2TB_251663803202 --add_storage 1 to create the PV/VG/thinpool and register it as Proxmox storage in one step. Result: storage ID ludo-lvm, ~1.8 TiB, content rootdir,images, nodes strong (mirrors hubris's library node-restriction pattern — this pool only physically exists here). Empty — no VM/CT disks placed on it yet.

2026-07-01 — Proxmox install; joined Homelab cluster

Reformatted from Linux workstation to Proxmox VE 9.2.3. SSH keys seeded from hubris's trusted set (root password used once, then discarded). Joined the existing Homelab cluster via pvecm add 192.168.8.77 --use_ssh 1 from this node's side, using key-based SSH pre-authorized in both directions — no interactive password prompt needed for the join itself. Cluster now 2 nodes (hubris, strong), quorate, no QDevice. Decided to leave hostname as strong and skip a QDevice for now — both revisitable later.