nanobot-runtime/projects/proxmox/state.md

State

Kontext a zkušenosti

• Proxmox provozuje dlouhodobě — jeden z domácích serverů, provozuje ho i v práci.
• Druhý domácí server je taky Proxmox.
• Zkušený Linux admin — preferuje CLI, líbí se mu, že všechno jde udělat z CLI.
• Odattendoval dvě vícedenní školení Proxmoxu: základy + pokročilý.

Hardware / současný stav

• RTX 4060 Ti / 16 GB passthrough do jedné VM.

Cíle / probíhající práce

• ZFS do hloubky — základy zná, chce hlubší porozumění. Materiály: viz sekce Studijní materiály níže.
• Proxmox Backup Server — vyzkoušel, líbí se. Plánovaný layout: SSD na rootfs, spiny disky na data, special vdev také na SSD.
• Migrace Hyper-V → Proxmox pro kamaráda: vyražený Dell Edge server, 2× 2 TB SSD (rootfs + VM disky). Přenos image z Hyper-V už úspěšně natrénoval. Potřeba: celý proces lépe popsat a naskriptovat.

Dlouhodobé cíle

• Atom server — znovupoužití 2TB šifrovaného disku z předchozího Debianu: používat ho dál ve stejném duchu — více partition, nad nimi LUKS a LVM (nad/pod LUKS). Napojit jako storage do Proxmoxu.
• rdiff-backup z jiného serveru — v LXC kontejneru na atom serveru zálohovat jiný server.
• Záloha Incus kontejneru — běží v něm hromada dockerů s různými službami včetně Gitey; data Gitey jsou kritická. Potřeba vymyslet spolehlivý zálohovací postup.
• Gitea: migrace z Incusu do Proxmoxu? — zvažuje přesun na PVE (VM/kontejner), čímž se záloha výrazně zjednoduší — standardní PBS záloha VM/kontejneru místo ad-hoc zálohování Incusu.
• Gitea Actions — chce GitHub Actions-compatible CI pro Giteu; runner jako další VM/kontejner na Proxmoxu (Gitea Actions, act_runner).
• PBS na atom serveru? — zvažuje, zda na atom serveru spustit Proxmox Backup Server jako zálohovací cíl pro hlavní Proxmox.

Hostname / přejmenování nodu

• Název nodu = kernel hostname (uname -n), ne DNS. Změna DNS záznamu Proxmoxu vůbec nevadí (ověřeno); změna /etc/hostname na nodu s VM rozběhne systém — VM se nenašly, vše se chovalo divně. Pomohl revert.
• Root cause: pmxcfs drží konfigurace VM/kontejnerů, certifikáty a metadata v /etc/pve/nodes/<hostname>/. Po změně hostname hledá pvedaemon konfigurace pod novým názvem, který v pmxcfs neexistuje → VM "zmizí".
• Správný postup (oficiální wiki Renaming a PVE node):
  1. Doporučeno jen na prázdném nodu — pmxcfs neumí přejmenovat neprázdné adresáře.
  2. Editovat /etc/hostname a /etc/hosts (všechny výskyty, hostname na hlavní IP). Volitelně /etc/mailname, /etc/postfix/main.cf.
  3. V clusteru: upravit n_0 v /etc/pve/corosync.conf přes pvecm edit corosync.conf — ale v clusteru se přejmenování nedoporučuje.
  4. Reboot.
  5. Ručně přenést /etc/pve/nodes/<starý>/ → <nový>/ (strukturu rekonstruovat, kopírovat po úrovních).
  6. Přenést RRD data: /var/lib/rrdcached/db/pve2-{node,storage}/<starý> → <nový>, starý smazat.
• Moudro: u nodu s běžícími VM stojí přejmenování tolik ruční práce, že je čistší postavit node pod novým názvem a VM migrnout. Revert hostname vše opraví — pmxcfs data nemaže, jen je "nezobrazí".

Studijní materiály — ZFS (uložené v bookmark skillu, db/bookmark.sqlite)

• ZFS 101 (Jim Salter, Ars Technica) — zpools, vdevy, RAIDZ vs mirror, ashift, CoW, ZIL/SLOG, komprese, ARC. Plný text archivován.
• ZFS vs RAID benchmark (Ars Technica) — 8× Ironwolf, mirrors vs RAID10, RAIDZ2 vs RAID6, vliv recordsize; výkon roste s počtem vdevů, ne disků. Plný text archivován.

Atompivo — hardware kontext

• Server atompivo: Proxmox, stavěný dřív, než bylo jasné finální využití.
• 1 TB SSD — celý disk na root fs nad ZFS (žádná volná partition).
• 2 TB spin disk — 5400 rpm, starší, aktuálně šifrovaná data (LUKS z předchozího Debianu); plánovaná přestavba na datastore. Další 2 TB spin disk k dispozici.

PBS datastore na atompivo — layout a tuning

• PBS poběží jako VM na atompivu (oficiálně podporované, běžné). Požadavky: celý disk passthrough pro spiny i pro special vdev (virtio-scsi), rezervovat dost RAM pro ARC (řádově 4-8 GB), atom = ingest spíš CPU-bound (SHA256/zstd).
• Chicken-egg: PBS VM zálohuje node, na kterém sama běží — umět PBS postavit znovu z ničeho; konfiguraci datastore + vzdump PBS VM držet mimo datastore (např. zfs send z root poolu na jiný stroj).
• Datastore pool na 2TB spiny (5400 rpm), tuning hned od založení:
  • recordsize=1M + logbias=throughput (doloženo na Proxmox foru: ingest 200 → 900 MB/s jen touto změnou)
  • special vdev na SSD — na 5400 rpm nutnost, ne nice-to-have: GC je metadata workload (readdir+stat nad miliony chunků); bez special vdevu ~20+ h denně, s ním minuty až desítky minut. GC defaultně běží denně.
  • special_small_blocks=64K — obsah malých chunků také na SSD; hlídat zaplnění special vdevu (zpool list -v), řádově desítky GB.
  • proxmox-backup-debug chunk-order — povinný na 5400 rpm: bez něj random read ~1-2 MB/s efektivně → verify týdny; s ním sekvenční read ~100-130 MB/s → ~5-6 h na 2 TB. Pustit po naplnění datastore a po velkých změnách znovu.
• Special vdev = zvol nad SSD root poolem (žádná volná partition):
  • Overhead nested CoW (write amplification ~2-3× na malých writzech, dvojité journaling vrstvy) — pro metadata na SSD irelevantní.
  • SPOF: ztráta SSD = ztráta celého poolu i se zdravými spiny. Akceptováno (GC bolí denně, ztráta SSD je hypotetický jednorázový event).
  • Nelze později odebrat, pokud top-level vdevy jsou raidz nebo ashifty neschodují (zpool remove restrikce) — topologii naplánovat předem; mirror spinů = odstranitelné, raidz = ne.
  • Special vdev lze naopak přidat kdykoliv (zpool add -o ... -special) — alternativní postup: založit bez něj, změřit, přidat.

Gitea → PVE migrace a zálohy

• Rozhodnuto: Gitea migruje z Incusu na Proxmox — standardní PBS záloha VM/kontejneru místo ad-hoc zálohování Incusu.
• Zálohovací cíl: PBS na atompivu (datastore viz výše).

Šifrování — co Proxmox umí a co ne

• PVE installer neumí šifrovaný root FS — žádná LUKS volba. LUKS root = ruční instalace Debianu + PVE na něj (komunitní návody: mr-manuel luks-encryption-manual-tpm-ssh-unlock, cmspam/proxmox-uki-installer). Feature request v Bugzille otevřený.
• Hardware TPM pro host unlock: PVE neumí, ale jde DIY — TPM2 sealing přes systemd-cryptenroll --tpm2 (nebo clevis) na Debian vrstvě; pro smysluplné PCR7 sealing vhodné/žádoucí Secure Boot. PVE samo TPM spravuje jen pro guesty (vTPM, Windows 11) — to je jiná věc než host unlock.
• ZFS native encryption = experimentální v PVE docs — známé limity: replikace encrypted datasets (Bugzilla 2350), checksum errory u snapshotů a ZVOLů (openzfs#11688). Žádná TPM integrace — jen passphrase/keyfile, zfs load-key ručně nebo systemd unit.
• Čistá cesta pro data disky: ZFS nad LUKS (/dev/mapper/... jako vdev zařízení) — osvědčený NAS pattern, TPM2 auto-unlock možný přes LUKS. Pozor: cryptsetup --sector-size 4096 pro ashift alignment.
• Atom caveat: zkontrolovat AES-NI (lscpu | grep aes) a přítomnost TPM čipu — bez AES-NI LUKS throughput na atomu výrazně padá.

Atompivo — reinstalace vs. stávající layout

• Problém: celý SSD patří rpoolu → žádná volná partition pro special vdev (jen zvol nad rpoolem) ani pro budoucí potřeby.
• Reinstalace overkill? Pro samotný special vdev ano (zvol stačí), ale node se právě přestavuje (data na spinu k přestavbě, Gitea se stěhuje dovnitř) — reinstalace nikdy nebude levnější než teď.
• Installer umí advanced options (menší HDSize → volné místo na SSD).
• Bonusy reinstalace: swap na partition místo rpool/swap ZVOLu (PVE wiki explicitně varuje před swap na zvolu), čistá partition pro special vdev (jedna vrstva ZFS, žádný nested CoW, nezávislost na rpoolu), LVM rezerva.
• Otevřená otázka: PBS VM vs. PBS v LXC — LXC by posunul ZFS pool datastore na host (žádný disk passthrough, special vdev = host partition/ zvol, LUKS pod ZFS řešený na hostu vč. TPM). Váže se na rozhodnutí o šifrování a layoutu.