upravy projektu a skillu

projects/proxmox/memory.md

@@ -5,4 +5,5 @@
 - 2026-08-31: Základní kontext — dlouholetý provoz Proxmoxu (doma i v práci), zkušený Linux admin, preferuje CLI. RTX 4060 Ti/16 GB passthrough do VM. Dvě vícedenní školení Proxmox (základy + pokročilý).
 - 2026-08-31: Tři témata: (1) ZFS do hloubky, (2) PBS layout SSD rootfs + spiny + special vdev na SSD, (3) migrace Hyper-V → Proxmox na Dell Edge (2× 2 TB SSD) pro kamaráda — popsat a naskriptovat.
 - 2026-08-31: Dlouhodobé cíle: znovupoužití 2TB LUKS+LVM disku na atom serveru, rdiff-backup kontejner, záloha Incus kontejneru s Giteou (kritická data), zvážení PBS na atom serveru jako target pro hlavní Proxmox.
-- 2026-08-31: Zvažuje migraci Gitey z Incusu na PVE (jednodušší zálohy přes PBS) + Gitea Actions runner (act_runner) jako další VM/kontejner.
+- 2026-08-31: Zvažuje migraci Gitey z Incusu na PVE (jednodušší zálohy přes PBS) + Gitea Actions runner (act_runner) jako další VM/kontejner.
+- 2026-09-01: Rozhodnuto — Gitea migruje na PVE (atompivo), záloha přes PBS. Datastore: 2TB spin 5400 rpm, special vdev na SSD (nutnost kvůli GC na 5400 rpm; bez něj ~20+h denně, s ním minuty). Special vdev jako zvol nad root SSD poolem — SPOF akceptován, nelze odebrat při raidz topologii. Tuning: recordsize=1M, logbias=throughput, special_small_blocks=64K, chunk-order pro verify. PBS jako VM, celý disk passthrough, ARC RAM rezerva, chicken-egg řešen zfs send konfigurace mimo datastore.

projects/proxmox/state.md

@@ -39,7 +39,112 @@
 - **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)](https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/) — zpools, vdevy, RAIDZ vs mirror, ashift, CoW, ZIL/SLOG, komprese, ARC. Plný text archivován.
 - [ZFS vs RAID benchmark (Ars Technica)](https://arstechnica.com/gadgets/2020/05/zfs-versus-raid-eight-ironwolf-disks-two-filesystems-one-winner/) — 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.