# Proxmox-Zielbild für "knaster" (Eingabe für platform/proxmox/tofu und ansible).
# Stand 12.10.2026: echte Knoten pve44–pve61. PCI-Adressen, IDs und IOMMU-Gruppen per
# `pvesh get /nodes/<knoten>/hardware/pci` gelesen. Gäste vorerst per DHCP (D5 zurückgestellt).
cluster:
  endpoint: https://192.168.100.210:8006/
  storage_iso: local
  bridge: vmbr0
  gateway: 192.168.100.1
  dns: 192.168.100.120
  ssh_public_key_file: ~/.ssh/id_ed25519.pub    # Schlüssel auf dem Steuerrechner ops
  lxc_template: debian-13-standard_13.6-1_amd64.tar.zst
  # Ubuntu-24.04-Cloud-Image-Template je Knoten (VMIDs sind clusterweit eindeutig)
  templates: {pve44: 9044, pve46: 9046, pve48: 9048, pve52: 9052}
  zfs_arc_max_mb: 2048        # ZFS-Lesecache der GPU-Knoten (tank trägt nur Replikate und kleine Gäste); Rolle pve-host

pci_mappings:                 # Proxmox Resource Mappings (Datacenter → Resource Mappings → PCI)
  gpu-m4000-pve44: {node: pve44, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
  gpu-p2000-pve44: {node: pve44, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
  gpu-m4000-pve46: {node: pve46, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
  gpu-p2000-pve46: {node: pve46, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
  gpu-m4000-pve48: {node: pve48, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}
  gpu-p2000-pve48: {node: pve48, path: "0000:02:00", id: "10de:1c30", subsystem_id: "10de:11b3", iommu_group: 8}
  gpu-m4000-pve52: {node: pve52, path: "0000:01:00", id: "10de:13f1", subsystem_id: "10de:1153", iommu_group: 1}

# Zuteilung je GPU-VM (15.10.): alle 8 Threads des Knotens und 20 von 32 GB. Der Rest des Knotens: Proxmox
# selbst ~3 GB, ZFS-ARC 2 GB (cluster.zfs_arc_max_mb), dazu ops (2 GB, pve46), infra (4 GB, pve44), k3s (3 GB, pve48).
# RAM der GPU-VMs ist durch PCI-Passthrough fest reserviert (kein Ballooning), CPU darf überbucht sein.
vms:                          # eine GPU-VM pro Knoten mit allen Karten des Knotens (D2)
  gpu-pve44: {node: pve44, vmid: 244, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve44, gpu-p2000-pve44], ip: dhcp, driver_generation: legacy}
  gpu-pve46: {node: pve46, vmid: 246, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve46, gpu-p2000-pve46], ip: dhcp, driver_generation: legacy}
  gpu-pve48: {node: pve48, vmid: 248, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve48, gpu-p2000-pve48], ip: dhcp, driver_generation: legacy}
  gpu-pve52: {node: pve52, vmid: 252, cores: 8, memory_mb: 20480, disk_gb: 40, models_disk_gb: 60, storage: local-lvm, gpus: [gpu-m4000-pve52], ip: dhcp, driver_generation: legacy}

containers:                   # Infrastruktur als LXC (ADR-0001), HA + ZFS-Replikation (ADR-0002)
  infra: {node: pve44, vmid: 101, cores: 4, memory_mb: 4096, disk_gb: 60, storage: tank, ip: 192.168.100.188/24, ha: true, replicate_to: [pve52, pve48]}

# Dienst-VMs ohne GPU (D6): k3s-Steuerung, geklont vom Template des Knotens, auf tank mit HA.
# Adresse per DHCP wie die GPU-VMs (D5); die Agents finden den Server über /etc/hosts (Rolle k3s-agent).
service_vms:
  k3s: {node: pve48, vmid: 110, cores: 2, memory_mb: 3072, disk_gb: 20, storage: tank, ip: dhcp, pool: infra, ha: true, replicate_to: [pve52, pve44]}

replication_schedule: "*/15"

# Cluster-Grundkonfiguration (Phase 4, Rolle pve-cluster, Playbook playbooks/cluster.yml)
access:
  admin_group: admins          # Gruppe mit Administrator auf /; root@pam bleibt Notfallzugang
  admin_users: [r.rapp]        # persönliche Konten <name>@pve; Passwort und TOTP per scripts/pve-admin-user.sh
  mail_to: ki@mygodel.de       # Ziel der Proxmox-Benachrichtigungen (Backup, Fencing, Updates, Replikation)
  # Verwaltung durch Personen statt durch ein Gerät (19.10., „Weg 1“): Jede Person kommt mit einem eigenen Schlüssel
  # auf ops (Bastion) und arbeitet von dort (kubectl, Ansible, tofu). Öffentliche Schlüssel, kein Geheimnis.
  # Ausrollen: playbooks/admins.yml auf ops. Übergabe und Entzug: docs/BETRIEB.md Abschnitt 15.
  ops_ssh_keys:
    - {name: r.rapp-laptop, key: "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHG5/rQMO4dtO8jOdAjQksFxZhdI7oSZAGNmFXVxQcoJ rrapp-laptop-2026-10-08"}
  ops_ssh_keys_revoked: []     # ehemalige Schlüssel ({name, key}); playbooks/admins.yml entfernt sie von ops
firewall:
  enable: true
  # IPSET management: nur diese Quellen (plus alle Knoten) erreichen 8006, 22, 5900-5999, 3128 und
  # 60000-60050 der Knoten. Corosync zwischen den Knoten erlaubt Proxmox von selbst.
  # Achtung: Der Laptop läuft per DHCP (D5). ops und infra haben seit 14.10. feste Adressen (noch ohne
  # Reservierung am DC). Wechselt die Laptop-Adresse, sperrt die Firewall diese Quelle aus. Rückweg: ssh über eine noch zugelassene Adresse (ops) oder Konsole.
  management:
    - {ip: 192.168.100.151, comment: Admin-Laptop WLAN per DHCP}
    - {ip: 192.168.100.181, comment: Admin-Laptop USB-LAN im Dock per DHCP}
    - {ip: 192.168.100.29, comment: appsrv08 LiteLLM mit PSE und n8n-Bruecke}
    - {ip: 192.168.100.173, comment: ops CT 100 Ansible und tofu statisch}
    - {ip: 192.168.100.188, comment: infra CT 101 pve-exporter statisch}
  ping_from: 192.168.100.0/24