# 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

- **proxmox.hell** (hlavní server): Dell OptiPlex 9020 Mini Tower, Intel Core i7-4790 @ 3.60GHz, 32GB RAM, GeForce RTX 4060 Ti 16GB, KINGSTON SKC3000D2048G 2TB NVMe, KINGSTON SUV5004 56RI 480GB SSD.
- 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)](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.