2026-10-12 14:18:18 +00:00
1 changed files with 36 additions and 9 deletions
@@ -31,7 +31,7 @@ Dieser Plan **löst** die Abläufe in `docs/PLAN.md` §8 („Roadmap“) und `do
 Alle Knoten: PVE 9.2.2, Kernel 7.0.2, **ext4 + LVM-thin auf einer SSD (kein ZFS)**, 1 GbE, kein Cluster. 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:** je eine RTX 4000 Ada mit 20 GB, Windows, tagsüber Arbeitsplätze. Sie laufen heute schon als LLM-Worker (`LocalLLMWorker.ps1`).
+- **GODE-PC-05/06:** laut Nutzer zwei Geräte mit vermutlich je einer RTX 4000 Ada (20 GB). Das Repo-Inventar nahm zwei Karten in einem Gerät an, deshalb wird das in Task 0.1 geprüft. 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.
@@ -71,6 +71,24 @@ Außerhalb des Clusters:
 | **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.
+
+| Gast | RAM | pve48 ohne GPU (Task 0.1) | pve48 mit GPU |
+|---|---|---|---|
+| `gpu-pve44`, `gpu-pve46`, `gpu-pve52` (ggf. `gpu-pve48`) | je 12 GB, fest | auf dem eigenen Knoten | auf dem eigenen Knoten |
+| `infra` (LXC) | 8 GB | pve48, Replikation nach pve44 | pve44, Replikation nach pve52 |
+| `ops` (LXC) | 1 GB | pve48 | pve46 |
+| `pbs` (VM) | 4 GB | pve48 | pve52 |
+| `grp-test` (LXC) | 4 GB | pve48 | pve46 |
+| pve61 | 8 GB gesamt | keine Gäste, nur Kiosk | 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
@@ -86,12 +104,13 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins
  Prüfung: `ssh -o BatchMode=yes pve48 hostname` → `pve48`.
 - [ ] **c:** Gesundheitscheck auf pve48 ausführen und `healthcheck-2026-10-08.txt` ergänzen. Notieren: CPU, RAM, Platten, GPUs, IOMMU-Gruppen.
 - [ ] **d (vor Ort, falls nötig):** pve52 – steckt neben der M4000 eine P2000? Falls ja: Sitz und Steckplatz prüfen, bis `lspci | grep -c NVIDIA` zwei VGA-Geräte zeigt. Verbleib von Godel45 klären (im STT-Plan aufgeführt).
+- [ ] **e:** Ada-Rechner GODE-PC-05/06: Karte und VRAM je Gerät mit `nvidia-smi -L` erfassen, an der Konsole oder über die Worker-Registry. Erwartet wird je Gerät eine Zeile `RTX 4000 Ada Generation`.

 ### 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).
+- [ ] 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.

@@ -110,11 +129,14 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins
 - Test: `core/tests/test_inventory_validate.py`

 **Interfaces:**
- Produces: Knotennamen `pve44`, `pve46`, `pve48`, `pve52`, `pve61`. PCI-Mappings `gpu-m4000-pve44`, `gpu-p2000-pve44`, `gpu-m4000-pve46`, `gpu-p2000-pve46`, `gpu-m4000-pve52` (plus pve48 nach Task 0.1). GPU-VMs `gpu-pve44` (vmid 244), `gpu-pve46` (246), `gpu-pve52` (252). Infra-LXC `infra` (vmid 101). Ansible-Gruppen `pve_all`, `pve_gpu_hosts`, `pve_kiosk`.
+- 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` (plus pve48 nach Task 0.1). GPU-VMs `gpu-pve44` (vmid 244), `gpu-pve46` (246), `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}`, `proxmox.yaml` enthält keine IP aus `10.20.0.0/24`, und jedes `pci_mappings[*].node` ist ein Inventar-Knoten.
+- [ ] **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 2:** `make test` → FAIL (alte Annahmen `pve-ada`, `pve1`–`pve4`).
- [ ] **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.5). Die Ada-Slots zeigen auf `engine: worker-registry` (siehe Task 6.4).
+- [ ] **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`.

@@ -145,7 +167,11 @@ Ersetzt PLAN §8 „0 Fundament“ (Teil Inventar) und IMPLEMENTATION „Gemeins

 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, iGPU als primäre Anzeige (GPU-Knoten). Installer: gleicher Hostname und gleiche IP wie bisher, `ZFS (RAID1)` bzw. `ZFS (RAID0)` bei einer Platte, `ashift=12`, `compress=on`.
+- [ ] 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`).
  Prüfung: `zpool status` → `ONLINE`. `pvesm status` → `local-zfs active`. `cat /sys/module/zfs/parameters/zfs_arc_max` → `4294967296` bzw. `1073741824`.
@@ -192,8 +218,9 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.

 - [ ] 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, pve52, ggf. pve48). 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.0` auf jedem GPU-Knoten → `Kernel driver in use: vfio-pci`. Auf pve61: `lspci -k -s 00:02.0` → `i915`.
+  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

@@ -248,7 +275,7 @@ Ersetzt GPU-Knoten 3 (Teil Cluster). Mit 5 Stimmen ist **kein QDevice** nötig.
 **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, 12 GB) mit HA und Replikation (Task 2.2). Compose mit `KNASTER_DRY_RUN=true`.
+- [ ] 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.
@@ -315,7 +342,7 @@ Am Ende von Phase 9 wird das Betriebshandbuch abgeschlossen („PVE-Config: Betr

 | # | Planner-Aufgabe | Warum jetzt |
 |---|---|---|
-| P1 | LiteLLM Swarm: PSE-Fix ausrollen (Klartext-Abfluss) | Datenschutz-Leck; Voraussetzung für D4 |
+| 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 |
 | P3 | NEX aufräumen: Testinstanz, Schlüsseldateien | `ca.key` liegt ungeschützt |
 | P4 | NEX: Gitea/Portainer-Schritte für Port je Agent und Registry (Teil 1 der Checkliste) | blockiert nex-admin |