@@ -49,6 +49,8 @@ Vorgehen pro Baustein: **Spec → Implementierung → Tests → Commit**. Bis zu
## Gemeinsames Deployment (später)
> **Abgelöst** durch [docs/superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort steht der Ablauf auf der echten Hardware, zusammengeführt mit Planner Epic 7. Die Liste unten bleibt nur zur Nachvollziehbarkeit stehen.
1. Inventarlauf auf allen Nodes → `sites/knaster/inventory.yaml` ergänzen → `knaster placement plan`
@@ -279,6 +279,8 @@ Die Portabilität beruht also auf den **Daten und der Pipeline**, nicht auf Gewi
## 8. Roadmap
> **Abgelöst** durch [superpowers/plans/2026-10-12-aufbau-cluster-knaster.md](superpowers/plans/2026-10-12-aufbau-cluster-knaster.md). Dort ist der chronologische Ablauf auf der echten Hardware beschrieben, mit den Entscheidungen D1–D5 und der Zuordnung zu Planner Epic 7. Die Tabelle unten bleibt nur zur Nachvollziehbarkeit stehen (Zuordnung: 0 → Phasen 0–5, 1 → 6, 2 → 7, 3–6 → 9).
| Phase | Inhalt | Fertig, wenn … |
|---|---|---|
| **0 Fundament** | Proxmox-Templates, Resource Mappings, OpenTofu/Ansible, Monitoring-Stack | eine GPU-VM lässt sich per Code neu erzeugen, Grafana zeigt GPU- und Proxmox-Metriken |
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** Die fünf installierten Proxmox-Knoten werden Schritt für Schritt zum Cluster „knaster“ ausgebaut, auf dem die Architektur aus `docs/PLAN.md` läuft. Grundlage sind die echte Hardware und die Aufgaben aus Planner Epic 7.
**Architecture:** Fünf Proxmox-Knoten mit ZFS bilden einen Cluster. Jeder GPU-Knoten bekommt **eine** Ubuntu-VM, an die alle seine Karten durchgereicht werden; darin laufen Docker-Container pro Rolle. Die Infrastruktur (Router, Postgres, Monitoring) läuft als LXC mit Docker und HA. Die beiden RTX-4000-Ada-Rechner bleiben Windows-Arbeitsplätze und stellen ihre Leistung über die vorhandene Worker-Registry v2 bereit. Starke Modelle laufen ausschließlich über den LiteLLM mit PSE auf appsrv08.
-`C:\Users\r.rapp\it\proxmox\STAND-2026-10-08.md` und `healthcheck-2026-10-08.txt` (Ist-Stand der Knoten)
- Repo `mygodel/nex`: `docs/plans/2026-10-07-nex-stt-gpu.md` (Whisper im Haus), `docs/plans/2026-09-29-nex-worker-registry-v2.md` (Ada-Worker)
Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `docs/IMPLEMENTATION.md` („Gemeinsames Deployment“) **ab**. Deren Phasen sind unten zugeordnet.
| pve61 | 192.168.100.214 | Surface Book, i5-8350U, 8 GB | 1× 256 GB NVMe | Intel UHD 620 | LAN nur über USB-NIC im Lenovo-Dock, 2 Akkus |
Alle Knoten: PVE 9.2.2, Kernel 7.0.2, **ext4 + LVM-thin auf einer SSD (kein ZFS)**, 1 GbE, kein Cluster.
Aufteilung der Systemplatte (per SSH geprüft, auf allen fünf Knoten gleich, alles noch leer): 69 GB `local` (System, ISOs, Vorlagen, lokale Backups), 141 GB `local-lvm` (Platten der VMs und Container), 8 GB Swap, 16 GB frei in der Volume Group. SMART: alle Platten `PASSED`. Samsung-SSDs (pve44, pve52) zu 3–17 % verschlissen, Surface-NVMe (pve61) zu 46 %. Bei der SanDisk in pve46 steht der Rohwert für umgelagerte Sektoren auf 100; der Wert wird überwacht. VT-x und VT-d sind aktiv. IOMMU ist geprüft: Jede Karte liegt mit ihrer Audio-Funktion in einer eigenen Gruppe (M4000 in Gruppe 1, P2000 in Gruppe 8), Passthrough ist also möglich.
Außerhalb des Clusters:
- **GODE-PC-05/06:** zwei Geräte mit je **einer RTX 4000 Ada (20 GB)** und **64 GB RAM** (Nutzer, 12.10.). Die CPU ist noch offen. `nvidia-smi` meldet 20475 MiB (`mygodel/scripts`, `tests/LocalLLMWorker.Tests.ps1`). Auf GODE-PC-06 läuft `llama-server` (CUDA, Port 8080) mit `Qwen3.8-27B-IQ4-MIX` (rund 15 GB), 32K Kontext, alle Layer auf der GPU, Stufe `expert` (`start-llama-server.ps1`). Job NEX-1 lief dort in 102 s erfolgreich. Das Repo-Inventar von cluster-knaster nahm zwei Karten in einem Gerät an; das wird in Task 0.4 korrigiert. Windows, tagsüber Arbeitsplätze, laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`).
- **appsrv08 (.29):** GRP produktiv, NEX und LiteLLM mit PSE-Filter.
- **n8n:** n8n.mindboost.app.
- **Gitea:** gitea.mindboost.team.
---
## Global Constraints
- **Starke Modelle (tier0, OpenRouter) nur über den LiteLLM mit PSE auf appsrv08.** Kein zweiter Gateway-Weg nach außen, sonst wird die Pseudonymisierung umgangen (Epic 7 „LiteLLM Swarm: PSE-Fix“).
- **Netz:** flach `192.168.100.0/24`, Gateway `.1`, DNS `.120`. Feste IP-Literale, kein DNS-Name in Konfigurationen, vorerst kein VLAN.
- **Container zuerst:** Dienste laufen als Docker-Container, in LXC oder in einer VM. Eine VM gibt es nur dort, wo sie ein Treiberproblem löst (GPU-VM pro Knoten, D2) oder ein Produkt sie verlangt.
- **Dry-Run:** Alle knaster-Aktionen gegen Infrastruktur starten mit `KNASTER_DRY_RUN=true` und werden erst nach einer Woche Beobachtung einzeln freigeschaltet.
- **STT:** `whisper-server` auf Port 8178, nur von `192.168.100.29` erreichbar. `stt.openai.base_url` nur als IP-Literal (nex-STT-Plan, Annahmen).
- **Ada-Rechner:** Windows bleibt, Mitarbeitende haben tagsüber Vorrang, kein Proxmox darauf.
- **Datacenter-weite Einstellungen** (Benutzer, 2FA, Firewall, Benachrichtigungen, Pools, Metriken) erst, wenn alle Knoten im Cluster sind.
- **Alte Windows-SSDs** (pve44 sdb, pve52 sdb) nur nach ausdrücklicher Freigabe löschen (D1).
- **Geheimnisse** nie ins Repo. Zugangsdaten liegen in `C:\Users\r.rapp\it\proxmox\.env`, der Schlüssel unter `…\proxmox\keys\`.
- **Planner-Webhook `tdo-codex-update`:** pro Aufruf nur **eine** Aktualisierung, vorhandene Titel nie umbenennen (Abgleich läuft über den Titel, Schwelle 0.8).
## Review Focus
1.**Eine Neuinstallation löscht die Einrichtung vom 08.10.** Betroffen sind Schlüssel, Paketquellen, Dock-Bindung und SSH-Hostschlüssel. Erwartung: Das Bootstrap-Skript stellt alles wieder her, und `ssh -o BatchMode=yes pveXX hostname` klappt danach ohne Nachfrage (Task 1.1, Test im Skript).
2.**Der Cluster-Beitritt ersetzt `authorized_keys`.** Erwartung: Nach jedem `pvecm add` funktioniert der Laptop-Zugang auf allen Knoten weiter (Task 2.1, Prüfschritt).
3.**Die USB-NIC von pve61 verschwindet nach einem Stromausfall oder einem Umstecken des Docks.** Erwartung: `vmbr0` hängt danach wieder an der Karte, ohne Eingriff (Task 1.3, Test: Dock aus- und einstecken).
4.**Ein Ada-Worker ist tagsüber belegt oder aus.** Erwartung: tier1-Anfragen landen ohne Fehler bei tier0 über PSE (Task 6.4, Unit-Test im Router).
5.**Die Rolle `pve-host` sperrt NVIDIA und setzt VFIO.** Erwartung: Das passiert nur auf GPU-Knoten. pve61 behält seine iGPU für den Kiosk (Task 3.1, Ansible-Gruppen, Prüfung `lspci -k`).
---
## Entscheidungen (vor der jeweiligen Phase bestätigen)
| **D1** | Speicher | **B – keine Neuinstallation:** Die System-SSD bleibt, wie sie ist. Die zweite SSD wird remote per SSH zum ZFS-Pool `tank` (pve44, pve48, pve52). pve46 und pve61 bleiben ohne ZFS. | Kein Einsatz vor Ort, und es bleibt mehr Platz für Gäste: 141 GB `local-lvm` plus 238 GB `tank` statt rund 200 GB auf einem Spiegel aus zwei 256-GB-Platten. Spiegeln ließe sich nur auf pve44, pve48 und pve52, pve46 und pve61 haben eine einzige Platte. Das entspricht dem ursprünglichen ADR-0002 („SSD 1 System, SSD 2+ `tank`“). Replikation und HA laufen zwischen pve44, pve48 und pve52. Ohne ZFS bleiben nur pve46 (GPU-VM und `ops`, beide brauchen kein HA) und pve61 (Kiosk). Fällt eine System-SSD aus, wird dieser Knoten neu installiert; die Gäste sind repliziert. | **A – Neuinstallation mit ZFS** (vor Ort, USB-Stick, Monitor, Tastatur): RAID1 auf Knoten mit zwei SSDs, `local-zfs` überall, Systemplatte gespiegelt, pve46 auf UEFI. Lässt sich später je Knoten nachholen. |
| **D2** | GPU als VM oder LXC | **Pro GPU-Knoten eine Ubuntu-24.04-VM mit allen Karten des Knotens**, darin Docker Compose pro Rolle. | Der Host-Kernel (7.0) bleibt ohne NVIDIA, Proxmox-Updates gefährden den Treiber nicht. R580 kommt als Ubuntu-Paket und ist per Snapshot rückrollbar. IOMMU-Gruppen sind geprüft. Eine VM pro Knoten statt pro Rolle (ADR-0001) spart RAM. Das Argument „gemischte Generationen“ aus ADR-0001 gilt im Cluster nicht mehr, alle Karten sind Maxwell/Pascal. Kosten: 2–5 % CPU, fest reservierter VM-RAM (12–16 GB von 32 GB). | LXC mit Host-Treiber: braucht R580 auf Kernel 7.0 oder einen festgehaltenen älteren Kernel. |
| **D3** | Ada-Rechner | **Windows bleibt.**`LocalLLMWorker.ps1` mit llama-server (CUDA) meldet sich über die Worker-Registry v2. Die knaster-Slots `tier1-general`/`tier1-flex` lösen auf einen Worker auf, der online ist, sonst tier0. | Die Registry v2 ist fast fertig (44 von 55 Schritten). Mitarbeitende werden nicht gestört. vLLM läuft unter Windows nicht nativ, Multi-LoRA, QLoRA und Qwen3-TTS kommen deshalb erst mit einer späteren WSL2-Entscheidung (Phase 9). | Dual-Boot mit Proxmox: scheidet aus, die Rechner werden tagsüber genutzt. |
| **D4** | LiteLLM | **Kein eigener LiteLLM im knaster-Infra.** Der Router nutzt den LiteLLM auf appsrv08 (mit PSE), die lokalen Slots werden dort als Modelle eingetragen. | Es läuft bereits ein dritter LiteLLM; noch einer würde PSE für tier0 umgehen. Ein Modellwechsel bleibt eine Datenänderung. | Eigener LiteLLM nur für lokale Slots, ohne OpenRouter-Zugang. |
| **D5** | IP-Plan | **Knoten behalten .207–.214.** Gäste bekommen einen festen Block außerhalb des DHCP-Bereichs. Vorschlag `.220–.239`, wird in Task 0.3 gegen den DHCP-Bereich geprüft. | Die STT-Konfiguration braucht IP-Literale. Die alten GODEL-DNS-Einträge zeigen, dass die Knoten-IPs aus DHCP stammen, deshalb Reservierungen anlegen. | VLAN `svc` (PLAN §1.4) später, wenn der Switch das zulässt. |
## RAM-Budget je Knoten
Bei einem Knoten mit 32 GB sind 6 GB fest belegt: 2 GB für den Host und 4 GB ZFS-ARC. Eine GPU-VM reserviert ihre 12 GB vollständig, Passthrough erlaubt kein Ballooning. Damit bleiben auf einem GPU-Knoten **14 GB** für Container und als Reserve für den Failover.
pve48 hat laut Inventar vom 12.10. M4000 und P2000 und ist damit der vierte GPU-Knoten. Im Einsatz sind insgesamt 4× M4000 und 3× P2000; pve52 hat nur die M4000.
| Gast | RAM | Knoten |
|---|---|---|
| `gpu-pve44`, `gpu-pve46`, `gpu-pve48`, `gpu-pve52` | je 12 GB, fest | auf dem eigenen Knoten |
| `infra` (LXC) | 8 GB | pve44 auf `tank`, Replikation nach pve52 und pve48 |
| `ops` (LXC) | 1 GB | pve46 (kein HA nötig, per Ansible neu aufsetzbar) |
| `pbs` (VM) | 4 GB | pve52 |
| `grp-test` (LXC) | 4 GB | pve48 auf `tank`, Replikation nach pve44 |
| pve61 | 8 GB gesamt | keine Gäste, nur Kiosk |
Regeln:
- Die Summe der Gäste je Knoten bleibt bei höchstens 26 GB (32 − 6).
- Das Replikationsziel von `infra` hat immer mindestens 8 GB frei, sonst scheitert der HA-Neustart still.
- Prüfung nach jedem neuen Gast: `pvesh get /nodes/<knoten>/status --output-format json | jq .memory`.
---
## Phase 0 – Bestandsaufnahme und Repo an die Wirklichkeit anpassen
Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeinsames Deployment“ Schritt 1.
### Task 0.1: Zugang zu pve48 und Inventar aller Knoten
**Wo:** Teil a vor Ort an der Konsole von pve48, Teil b remote · **Planner:** „Proxmox: pve48 root-Passwort klären und SSH-Schlüssel nachtragen“
- [x]**a:** Richtiges Passwort in `.env` (`PVE48_PASS`) eingetragen (12.10., der alte Wert war falsch).
- [x]**b:** Schlüssel verteilt (`push_keys.py pve48`), Paketquellen auf `pve-no-subscription` umgestellt (Sicherung `/root/apt-backup-2026-10-12/`, 184 Updates offen, kein Upgrade).
- [x]**c:** Inventar pve48 (12.10.): P310, i7-6700, 32 GB, Legacy-Boot, VT-d aktiv, M4000 in Gruppe 1, P2000 in Gruppe 8, 1 GbE, Wake-on-LAN `g`, SMART aller drei Platten `PASSED`. Eingetragen in Ausgangslage und `healthcheck-2026-10-08.txt`.
- [x]**d:** pve52 hat nur die M4000, eine P2000 ist dort nicht verbaut (Nutzer, 12.10.). Es sind 3× P2000 im Einsatz (pve44, pve46, pve48).
- [ ]**d2:** Verbleib von Godel45 klären (im STT-Plan aufgeführt).
- [x]**e:** Ada-Rechner GODE-PC-05/06: je Gerät eine RTX 4000 Ada (20 GB) und 64 GB RAM (Nutzer, 12.10.).
- [ ]**e2:** CPU der Ada-Rechner erfassen, nebenbei aus dem Heartbeat der Worker-Registry v2 (`cpuCores`) oder mit `Get-CimInstance Win32_Processor`.
### Task 0.2: DHCP-Bereich und IP-Plan (D5)
**Wo:** remote (DHCP-Server, vermutlich DC `.120` oder UniFi) · **Planner:** „PVE-Config: Netzwerk prüfen – Bridge, VLAN-Fähigkeit und NIC-Kompatibilität“
- [ ] DHCP-Bereich auslesen. Für .207, .209, .210, .212 und .214 Reservierungen auf die MACs der Knoten anlegen (MACs stehen im Healthcheck). Ebenso eine Reservierung für den Admin-Laptop (heute .151 per WLAN). Die Firewall in 4.4 lässt nur diese Adresse zu, ein Lease-Wechsel würde sonst aussperren.
- [ ] Gäste-Block festlegen (Vorschlag `.220–.239`) und als Ausschluss im DHCP eintragen.
Prüfung: `ping` auf jede Adresse des Blocks → keine Antwort. DHCP-Ausschluss sichtbar.
### Task 0.3: Entscheidungen D1–D5 bestätigen
**Wo:** Gespräch mit dem Nutzer
- [x] D1 entschieden (12.10.): **Variante B**, keine Neuinstallation. Alle alten Windows-Platten werden für den Cluster vollständig gelöscht.
- [ ] D1-Freigabe zum Löschen: Der Nutzer prüft die alten Windows-Platten zuerst (pve44 sdb NTFS, pve52 sdb BitLocker „GODEL55“, pve48 sdb mit 220 GB und sdc mit 101 GB belegt). Gelöscht wird erst nach seinem ausdrücklichen „Freigabe“.
- [ ] D2–D5 bestätigen. Ergebnis als Abschnitt „Entscheidungen 2026-10“ in `docs/PLAN.md` §9 eintragen.
### Task 0.4: Site-Dateien, Ansible-Inventar und ADRs an die echte Hardware anpassen
- Modify: `docs/adr/0001-gpu-vms-infra-lxc.md` (eine VM pro Knoten), `docs/adr/0002-storage-zfs-kein-ceph.md` (D1), `docs/adr/0006-legacy-gpus-llamacpp-tts-auf-ada.md` (Ada unter Windows, D3)
- Test: `core/tests/test_inventory_validate.py`
**Interfaces:**
- Produces: Proxmox-Knoten `pve44`, `pve46`, `pve48`, `pve52`, `pve61`, dazu die Inventar-Knoten `gode-pc-05` und `gode-pc-06` (Ada, ohne Proxmox, nur im Inventar). PCI-Mappings `gpu-m4000-pve44`, `gpu-p2000-pve44`, `gpu-m4000-pve46`, `gpu-p2000-pve46`, `gpu-m4000-pve52`, `gpu-m4000-pve48`, `gpu-p2000-pve48`. GPU-VMs `gpu-pve44` (vmid 244), `gpu-pve46` (246), `gpu-pve48` (248), `gpu-pve52` (252). Infra-LXC `infra` (vmid 101). Ansible-Gruppen `pve_all`, `pve_gpu_hosts`, `pve_kiosk`.
- [ ]**Step 1: Failing test.** In `test_inventory_validate.py` den Test `test_site_knaster_matches_real_nodes` anlegen:
- Die Inventar-Knoten sind genau `{pve44, pve46, pve48, pve52, pve61, gode-pc-05, gode-pc-06}`.
-`proxmox.yaml` enthält keine IP aus `10.20.0.0/24`.
- Jedes `pci_mappings[*].node` und jedes `vms[*].node` liegt in `{pve44, pve46, pve48, pve52}`.
- [ ]**Step 3:** Site-Dateien umschreiben. Werte für IDs und Pfade aus `lspci -nn` und dem Healthcheck: M4000 `10de:13f1` auf `0000:01:00`, P2000 `10de:1c30` auf `0000:02:00`. Gateway `192.168.100.1`, DNS `192.168.100.120`, keine `vlan_svc`, Gast-IPs aus D5. Die M4000 bleiben `disabled: true` bis zum Benchmark-Tag (Task 3.3). Die Ada-Slots (`tier1-general`, `tier1-flex`, `tts-de-hq`) behalten vorerst ihre Engine. In `registry.yaml` entfallen bei ihnen nur `pve_node` und `vmid`. Die Umstellung auf die Worker-Registry folgt in Task 6.4.
- [ ]**Step 4:**`make test && make validate` → PASS. `knaster placement plan --inventory sites/knaster/inventory.yaml` liefert eine Zuordnung ohne Fehler.
- [ ]**Step 5:** Commit `sites: Inventar und Zielbild an echte Knoten (pve44–pve61) angepasst; ADR-0001/0002/0006 ergänzt`.
---
## Phase 1 – Knoten-Grundlage (vor dem Cluster)
### Task 1.1: Bootstrap-Skript für einen frischen Knoten
- Produces: `bootstrap-node.sh <knoten>`, idempotent. Ausgabe endet mit `BOOTSTRAP OK <hostname>` oder Exit ≠ 0.
- [ ]**Step 1:** Das Skript (läuft auf dem Laptop, Git-Bash) erledigt Folgendes:
- alten Hostschlüssel mit `ssh-keygen -R <ip>` entfernen
- Schlüssel per Passwort aus `.env` eintragen, mit dem SSH_ASKPASS-Verfahren vom 08.10. (nur anhängen, `grep -qxF`)
- Enterprise-Quellen auf `Enabled: no` setzen, `proxmox.sources` mit `pve-no-subscription` anlegen, vorher sichern
-`apt-get update && apt-get -y full-upgrade`
- Pakete `ethtool lm-sensors` installieren
- Prüfen: `timedatectl show -p NTPSynchronized` = `yes`
- [ ]**Step 2:** Zweiter Lauf gegen denselben Knoten → keine Änderung, wieder `BOOTSTRAP OK`.
- [ ]**Step 3:** Commit.
### Task 1.2: Speicher (D1)
**Planner:** „Proxmox: Speicher aller Knoten richtig konfigurieren“ (enthält die frühere Aufgabe zur RAM-Planung)
**Variante B (Empfehlung) – remote, ohne Neuinstallation**
- [ ] Freigabe aus Task 0.3 liegt vor. Dann auf pve44, pve48 und pve52: Partitionen von `sdb` mit `wipefs -a /dev/disk/by-id/<ssd2>` entfernen, danach `zpool create -o ashift=12 -O compression=lz4 -O atime=off tank /dev/disk/by-id/<ssd2>` und `pvesm add zfspool tank --pool tank --content images,rootdir --nodes pve44,pve48,pve52`. Auf pve48 bleibt `sdc` unberührt.
Das Löschen ist nicht umkehrbar. Vorher `lsblk -o NAME,SIZE,FSTYPE,LABEL /dev/sdb` prüfen: Es muss die freigegebene Windows-Platte sein, nie `sda`.
- [ ] ZFS-ARC auf 4 GiB begrenzen (`/etc/modprobe.d/zfs.conf`, `update-initramfs -u`, wirksam beim nächsten Neustart).
Prüfung: `zpool status tank` → `ONLINE`. `pvesm status` → `tank active` auf beiden Knoten.
**Variante A – Neuinstallation mit ZFS**
**Wo:****vor Ort**, USB-Stick mit PVE 9.2 (ISO und Prüfsumme in `C:\Users\r.rapp\it\proxmox`)
Reihenfolge: **pve46** (eine Platte, Legacy → UEFI), dann pve44, pve52, pve48 und zuletzt **pve61 mit angestecktem Dock** (der USB-C-Adapter ist zurückgegeben).
- [ ] Pro Knoten: BIOS auf UEFI, Secure Boot aus. Installer: gleicher Hostname und gleiche IP wie bisher, `ZFS (RAID1)` bzw. `ZFS (RAID0)` bei einer Platte, `ashift=12`, `compress=on`.
- [ ]**Prüfpunkt iGPU (GPU-Knoten):** Im BIOS die Onboard-Grafik als primäre Anzeige einstellen und den Monitor ans Mainboard anschließen.
Prüfung: Die Proxmox-Konsole erscheint am Mainboard-Anschluss.
Rückfall, falls das BIOS die iGPU bei eingesteckter Karte abschaltet: die P2000 in Steckplatz 1 und die M4000 in Steckplatz 2 tauschen. Die Boot-Grafik ist dann die P2000; für sie gilt beim Passthrough in Task 3.2 `x-vga`/ROM-Prüfung.
- [ ] Neues root-Passwort trägt der Nutzer **vor** dem nächsten Schritt in `.env` ein (`PVExx_PASS`), sonst scheitert das Bootstrap-Skript.
- [ ] Danach `bootstrap-node.sh <knoten>` → `BOOTSTRAP OK`.
- [ ] ZFS-ARC begrenzen: `zfs_arc_max` = 4 GiB auf 32-GB-Knoten, 1 GiB auf pve61 (`/etc/modprobe.d/zfs.conf`, `update-initramfs -u`).
### Task 1.3: pve61 – Netzwerk am Dock robust machen, Akku schonen
**Wo:** remote, Akku-Einstellung vor Ort · **Planner:** Teil von „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
- [ ] NIC des Docks per systemd-`.link` auf den Namen `nic0` festlegen, Zuordnung über die MAC `3c:e1:a1:c0:83:9d`. `bridge-ports nic0` in `/etc/network/interfaces`. Nach dem Ausstecken hängt ein `udev`-Hook `ifup`/`ifreload` die Karte wieder an `vmbr0`.
- [ ]**Test (vor Ort):** Dock 10 s ausstecken und wieder einstecken → nach höchstens 30 s `ping 192.168.100.214` vom Laptop ok.
Prüfung: `grep . /sys/class/power_supply/BAT*/capacity` pendelt bei etwa 50 %.
---
## Phase 2 – Cluster
Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
### Task 2.1: Cluster „knaster“ bilden
**Wo:** remote · **Planner:** „GPU-Knoten 3: Cluster mit QDevice (Container auf appsrv08), NVIDIA-Treiber, GPU-Container“ (Teil Cluster)
- [ ] Auf pve44: `pvecm create knaster --link0 192.168.100.210`.
- [ ] Nacheinander auf pve46, pve48, pve52 und pve61: `pvecm add 192.168.100.210 --link0 <eigene IP>`. Nach **jedem** Beitritt den Laptop-Schlüssel in `/etc/pve/priv/authorized_keys` prüfen und gegebenenfalls einmal ergänzen.
Prüfung: `pvecm status` → `Quorate: Yes`, `Total votes: 5`. `for n in pve44 pve46 pve48 pve52 pve61; do ssh -o BatchMode=yes $n hostname; done` → fünf Namen.
- [ ] Datacenter-Optionen: Migrationsnetz `192.168.100.0/24`, Typ `secure`.
### Task 2.2: HA-Regeln und Replikation
**Wo:** remote
- [ ] Node-Affinity-Regeln: Infra-Dienste nur auf pve44, pve48, pve52. **pve61** bekommt keine HA-Gäste, GPU-VMs bleiben an ihrem Knoten.
- [ ] Replikationspartner festlegen: Infra-LXC von seinem Knoten auf einen zweiten, `*/15`.
Prüfung: `ha-manager rules config` bzw. `ha-manager groupconfig` zeigt die Regeln.
---
## Phase 3 – GPU-Grundlage und Benchmark-Tag
### Task 3.1: Steuerrechner „ops“ und Host-Rolle nur für GPU-Knoten
- [ ] LXC `ops` (Debian 13, vmid 100, auf pve44, IP aus D5) mit `ansible-core`, `opentofu`, `git` und dem Repo-Clone. Ansible läuft nicht auf dem Windows-Laptop.
- [ ]`site.yml`: `pve-host` nur für `pve_gpu_hosts` (pve44, pve46, pve48, pve52). pve61 steht in `pve_kiosk` ohne VFIO und Blacklist.
- [ ] Rolle `pve-host` ergänzen: `/etc/modprobe.d/vfio.conf` mit `options vfio-pci ids=<liste>` und `softdep nvidia pre: vfio-pci`. Die Liste enthält die Grafik- **und** die Audio-Funktionen der Karten. Die IDs aus `lspci -nn -s 01:00` und `lspci -nn -s 02:00` auf dem Knoten lesen, nicht aus dem Gedächtnis eintragen; bekannt sind bisher nur die VGA-IDs `10de:13f1` und `10de:1c30`.
- [ ]`ansible-playbook playbooks/site.yml --limit pve_gpu_hosts --check`, danach der echte Lauf. Knoten **einzeln** neu starten.
Prüfung: `lspci -nnk -s 01:00` und `lspci -nnk -s 02:00` auf jedem GPU-Knoten → bei allen Funktionen `Kernel driver in use: vfio-pci`. Auf pve61: `lspci -k -s 00:02.0` → `i915`.
### Task 3.2: Resource Mappings, Template und GPU-VMs
- [ ] PCI-Resource-Mappings aus `sites/knaster/proxmox.yaml` anlegen (Namen aus Task 0.4).
- [ ] Ubuntu-24.04-Cloud-Template vmid 9000 auf jedem GPU-Knoten.
- [ ]`tofu plan` und dann `tofu apply` für `gpu-pve44`, `gpu-pve46`, `gpu-pve48` und `gpu-pve52`: alle Karten des Knotens, 12 GB RAM, 4 Kerne, Systemplatte 40 GB und Modellplatte 60 GB auf `local-lvm` (Variante B) bzw. `local-zfs` (Variante A), IPs aus D5.
Prüfung in jeder VM: `nvidia-smi -L` → beide Karten. `docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu24.04 nvidia-smi` → beide Karten.
### Task 3.3: Benchmark-Tag (fasst drei Pläne zusammen)
**Wo:** remote, **Strommessung vor Ort** (Messgerät an der Steckdose) · **Planner:** „GPU-Knoten 4: Geschwindigkeitstests (Gate) auf M4000 und P2000“ · ersetzt außerdem den „Benchmark-Tag“ aus IMPLEMENTATION und den Gate-Task 1 des nex-STT-Plans
- [ ]`llama-bench` je Kartentyp: Embedding-Modell, 3–4B Q4 (verifier/signature), 7B Q4. Tokens/s und VRAM messen.
- [ ] whisper.cpp `large-v3-turbo`, Sprache `de`: Sekunden je 10 s Diktat auf M4000 und P2000. Klärt, ob CC 5.2 überhaupt rechnet. Zusätzlich die Dialekt-Testsätze.
- [ ]`knaster bench tts` (Piper, CPU).
- [ ] Strom je Knoten: Leerlauf und Volllast beider Karten (400-W-Netzteil, erwartet etwa 300 W).
- [ ] Ergebnis eintragen in `catalog/models.yaml` und `sites/knaster/registry.yaml`, in ADR-0006 „M4000 wieder aufnehmen ja/nein“ und in die STT-Entscheidung D131/D133 (nex). Commit.
Prüfung: `make validate` → PASS, Placement ordnet jede aktive Rolle einer gemessenen Karte zu.
---
## Phase 4 – Cluster-Grundkonfiguration (erst wenn alle Knoten drin sind)
**Wo:** remote. Jede Aufgabe hier entspricht einer Planner-Aufgabe.
- [ ]**4.1 Benutzer und Token** („PVE-Config: Persönlicher Admin-Benutzer, Rollen und API-Token anlegen“): Admin-Benutzer und Gruppe, root@pam nur als Notfallzugang. Token `monitoring@pve!prom` (PVEAuditor), `healer@pve!knaster` (nur `VM.PowerMgmt` auf GPU-VMs, PLAN §3), `tofu@pve!ops`.
- [ ]**4.2 2FA** („PVE-Config: Zwei-Faktor-Authentifizierung für Admin-Konten aktivieren“): TOTP für root@pam und Admin. Recovery-Keys offline ablegen.
- [ ]**4.3 Benachrichtigungen** („PVE-Config: Benachrichtigungen (Notification Center) einrichten“): SMTP-Ziel Büro-Postfach, Matcher für Backup, Fencing und Updates. Testnachricht kommt an.
- [ ]**4.4 Firewall** („PVE-Config: Firewall auf Datacenter- und Knotenebene einrichten“): IP-Set `admin` (Laptop) und `appsrv08` (.29). Zuerst Allow-Regeln für 8006, 22 und ICMP, **dann** aktivieren. Konsole als Rückfall bereithalten. Prüfung: Weboberfläche vom Laptop ok, von einem anderen Rechner gesperrt.
- [ ]**4.5 Ordnung** („PVE-Config: Ressourcenpools und Tags festlegen“, „PVE-Config: Standard für neue LXC-Container festlegen“): Pools `infra`, `gpu`, `test`. Tags `gpu`, `infra`, `test`. LXC-Standard: unprivilegiert, Debian-13-Vorlage, Nesting nur für Docker.
- [ ]**4.6 Zertifikat** („PVE-Config: Web-GUI-Zertifikat festlegen (niedrige Priorität)“): `/etc/pve/pve-root-ca.pem` auf dem Laptop als vertrauenswürdig importieren.
- [ ]**4.7 Update-Routine** („PVE-Config: Update- und Neustart-Routine festlegen (rollierend, Knoten für Knoten)“): Ablauf in `docs/BETRIEB.md` eintragen (Wartungsmodus, ein Knoten nach dem anderen, GPU-VMs vorher sauber stoppen).
---
## Phase 5 – Backup und Monitoring
### Task 5.1: Proxmox Backup Server
**Wo:** remote, Speicherort vor Ort · **Planner:** „Proxmox: Backup-System überlegen“ (beantwortet PLAN §9, offener Punkt 6)
- [ ] Ziel-Speicher entscheiden. Empfehlung: externer Datenträger oder NAS, **nicht** die Toshiba-Platte „BACKUP“ des Nutzers. PBS als VM `pbs` (vmid 110), Datastore auf dem Ziel.
- [ ] Jobs: nächtlich Infra-LXC, ops-LXC und GPU-VMs (ohne Modellplatte), Aufbewahrung 7 Tage, 4 Wochen und 6 Monate. Dazu ein wöchentlicher Verify-Job.
- [ ]**Restore-Test:** Infra-LXC als Kopie zurückspielen.
Prüfung: Die Kopie startet, `docker ps` zeigt die Dienste.
### Task 5.2: Infra-LXC mit Monitoring (ein Stack)
**Wo:** remote · **Planner:** „Proxmox: Grafana-Dashboard für den Cluster“, „PVE-Config: Verfügbarkeits-Monitoring und Log-Kontrolle ergänzen“ · **Files:** Modify `deploy/compose/infra/docker-compose.yml`, `deploy/prometheus/prometheus.yml`
- [ ]`deploy/compose/infra` ohne den Dienst `litellm` (D4). Router zeigt auf `http://192.168.100.29:<LiteLLM-Port>`. Image-Tags pinnen (offener Punkt aus IMPLEMENTATION).
- [ ] LXC `infra` (vmid 101, Nesting, 4 Kerne, 8 GB, Knoten laut RAM-Budget) mit HA und Replikation (Task 2.2). Compose mit `KNASTER_DRY_RUN=true`.
- [ ] Prometheus-Ziele: `pve-exporter` (Token aus 4.1), `node-exporter` und `nvidia_gpu_exporter` in den GPU-VMs, Router.
- [ ] Grafana: Dashboards für Proxmox, Knoten, GPU (Community-JSON) und knaster. Konto `kiosk` mit Rolle Viewer.
- [ ] Alertmanager an den Router (Healer, Dry-Run) und an n8n `knaster-notify`. Der Workflow wird inaktiv importiert, dann aktiviert.
Prüfung: Grafana zeigt alle 5 Knoten und alle GPUs. Ein Test-Alert (`amtool alert add test`) erscheint im Kanal.
### Task 5.3: Kiosk auf pve61
**Wo:** remote, Abnahme vor Ort · **Planner:** „Proxmox: pve61 (Surface) zeigt das Grafana-Dashboard als Kiosk“
- [ ] Empfehlung: minimaler Kiosk **direkt auf dem Host** (`cage` + `chromium` als eigener Benutzer, systemd-Dienst, Bildschirmschoner aus). Das ist eine bewusste kleine Ausnahme von „Container zuerst“, weil ein Kiosk Bildschirm und Eingabe des Geräts braucht.
- [ ] URL: Grafana-Playlist im Kiosk-Modus mit Konto `kiosk`.
Prüfung: Nach einem Neustart von pve61 zeigt der Bildschirm ohne Eingriff das Dashboard.
---
## Phase 6 – Data Plane
Ersetzt PLAN §8 „1 Data Plane“.
- [ ]**6.1 GPU-Rollen:**`deploy/compose/gpu-llamacpp` in den GPU-VMs nach der Zuordnung aus Task 3.3, also Embedding und Rerank redundant auf zwei Knoten, Chat für verifier und signature. Prüfung: Canary-Checks grün (`knaster` Canary-Prober).
- [ ]**6.2 STT** (nex-STT-Plan Tasks 2–4): `whisper-server` als zusätzlicher Dienst in der GPU-VM des in Task 3.3 gewählten Knotens. Neuer Slot `stt-de` im Katalog. Port 8178 nur von `192.168.100.29` (Firewall der VM bzw. des Gasts). Prüfung: Von appsrv08 liefert `curl -F file=@probe.wav http://<IP>:8178/v1/audio/transcriptions` deutschen Text, von einem anderen Rechner wird der Zugriff abgelehnt.
- [ ]**6.3 Lokale Slots in LiteLLM (D4):**`embed-default`, `rerank-default`, `verifier-small` und `signature-extractor` als Modelle im LiteLLM auf appsrv08 eintragen (IP-Literale). Prüfung: `curl http://192.168.100.29:<port>/v1/models` listet die Slots, ein Aufruf je Slot antwortet.
- [ ]**6.4 Ada-Worker (D3)** · **Planner:** „LLM-Worker: direkte Inferenz-Schnittstelle für LiteLLM (zusätzlich zum Job-Poll), Tunnel, Registry, Fallback-Kette“
- Offene Schritte der Worker-Registry v2 im Repo `mygodel/nex` abschließen.
- Gefilterte Ports auf GODE-PC-05/06 freigeben (nex-STT-Plan, Anhang A).
- Im knaster-Router `engine: worker-registry` umsetzen: `GET /webhook/llm-worker-list` lesen und einen Worker wählen, der online ist; sonst Eskalation auf tier0.
- Prüfung: `make test` PASS. Live tagsüber geht eine tier1-Anfrage an tier0, nachts an GODE-PC-05.
---
## Phase 7 – Kernpfad
Ersetzt PLAN §8 „2 Kernpfad“.
- [ ] n8n-Workflows `knaster-request`, `knaster-jobs` und `knaster-service-routine` inaktiv importieren und Credentials setzen (`n8n/README.md`).
- [ ] Ende-zu-Ende: Eine Anfrage läuft über Router, Verifier und Eskalation über den PSE-LiteLLM. Die Dry-Run-Woche beginnt.
- [ ] Nex-STT-Plan Tasks 5–8: Hermes-Overlay `stt.openai.base_url` mit IP-Literal, Rückfall auf CPU, Abnahme.
- [ ] Offen und hier zu entscheiden: Langfuse (PLAN §2.4) steht nicht im Infra-Compose.
## Phase 8 – GRP als Testdienst
**Planner:** „Proxmox: GRP als Testservice in einen LXC-Container umziehen“ · **Voraussetzung:** PBS (Task 5.1)
- [ ] LXC `grp-test` (Pool `test`, Docker) mit einer Kopie der GRP-Daten von appsrv08. Die Produktion bleibt unangetastet. Feste IP aus D5, Zugriff nur intern.
Prüfung: Die Testinstanz läuft, das Backup des Containers ist im PBS sichtbar.
## Phase 9 – knaster-Ausbau (eigene Pläne folgen)
Die Software-Phasen aus PLAN §8 bleiben inhaltlich gültig und bekommen jeweils einen eigenen Plan:
- „5 Lifecycle“: QLoRA-Training. Voraussetzung ist die Entscheidung über WSL2 bzw. vLLM auf den Ada-Rechnern nachts (D3, Folgeentscheidung).
- „6 Portabilität“
Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betriebshandbuch und Testvorgehen anlegen“). Das geschieht als Erweiterung von `docs/BETRIEB.md`, nicht als neues Dokument.
---
## Parallelspur NEX (ohne Cluster-Bezug, nach Dringlichkeit)
| # | Planner-Aufgabe | Warum jetzt |
|---|---|---|
| P1 | LiteLLM Swarm: PSE-Fix ausrollen (Klartext-Abfluss) | Datenschutz-Leck auf dem Swarm (D4 nutzt den schon reparierten LiteLLM auf appsrv08) |
| P2 | NEX: Startpasswort astreit ändern | Passwort lag lesbar in S:\IT\Nex |
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.