[Plan] Neuer Proxmox-Host (Jellyfin + Uebersetzung): Setup-Checkliste von Grund auf #107
Labels
No labels
flugscanner
fuenfvoracht
infrastruktur
jarvis
ki-tower
nice-to-have
prio-1
wartung
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: orbitalo/homelab-brain#107
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Zweck
Dedizierter neuer Rechner als Proxmox-Host fuer Jellyfin + die Echtzeit-Uebersetzung (Jervais, siehe #103). Diese Checkliste ist der verbindliche Aufbauplan, damit JEDE Cline-/Cursor-Session ihn abrufen kann (statt fluechtiger Chat-Versprechen). Trigger: Sobald der Host installiert/online ist und IP + root-Zugang vorliegen, wird nach dieser Liste gearbeitet.
Hardware (Stand 14.06.2026)
WICHTIGSTE ARCHITEKTUR-ENTSCHEIDUNG: GPU wird GETEILT, NICHT durchgereicht
KEIN VM-GPU-Passthrough (VFIO)! Passthrough gibt die ganze Karte EXKLUSIV an eine VM -> dann koennte die Uebersetzung die 3080 nicht mehr nutzen. Das widerspricht dem Plan.
Stattdessen: LXC-Container mit geteiltem GPU-Device. Der NVIDIA-Treiber laeuft auf dem Proxmox-HOST, und die /dev/nvidia*-Nodes werden in mehrere unprivilegierte LXC gemountet. So teilen sich Jellyfin (NVENC/NVDEC) und Uebersetzung (CUDA-Compute) dieselbe 3080 - verschiedene Engines, koexistieren problemlos. Vorteil: kein IOMMU/VFIO noetig, kein nouveau-Gefummel in VMs.
Die iGPU des 5600G treibt die Konsole -> die 3080 wird vom Host-Display nicht belegt und steht voll zur Verfuegung.
Phase A - Konsole/BIOS (NICHT remote machbar - braucht physischen/Konsolen-Zugang)
Phase B - Proxmox-Grundkonfiguration (remote per SSH)
apt update && apt full-upgrade, reboot.Phase C - ZFS-Pool
ashift=12,compression=zstd).media(Jellyfin),backups, ggf.appdata.Phase D - NVIDIA-Treiber auf dem HOST (Fundament fuers Sharing)
nouveaublacklisten.nvidia-smimuss die 3080 zeigen.nvidia-persistenced).--no-kernel-module).Phase E - GPU-Sharing in LXC einrichten
lxc.cgroup2.devices.allow+lxc.mount.entryfuer/dev/nvidia0,/dev/nvidiactl,/dev/nvidia-uvm,/dev/nvidia-uvm-tools.--no-kernel-module),nvidia-smiim Container testen.Phase F - Jellyfin-LXC
media-Dataset mounten.Phase G - Uebersetzungs-Pipeline-LXC (Details in #103)
Phase H - Cloudflared / externer Zugang
Phase I - Monitoring-Integration
Phase J - Backup (PBS)
pbs-muldensteinaufnehmen.Phase K - Doku-Migration
hosts/*.md), je Container eincontainer/ct-XXX-*.md.credentials.md.Offene Punkte / zu klaeren
Hinweis fuer den ausfuehrenden Agenten
Phase C konkretisiert - Datentraeger fuer ZFS-Pool
Verbaute Platte: 1x Seagate Desktop HDD.14, ST2000DM001, 2 TB, SATA 6 Gb/s, 7200 RPM, Desktop-HDD (keine NAS-/Enterprise-Platte).
Kritische Einordnung (wichtig!)
Entscheidung / Regeln fuer diese Platte
backups-Dataset aus Phase C STREICHEN. Backups gehoeren auf pbs-muldenstein (siehe Phase J).smartctl -t long, danach Reallocated_Sector_Ct + Current_Pending_Sector pruefen. Schon Reallocations -> Platte NICHT verwenden.smartdeinrichten -> Frueh-Warnung bei beginnendem Plattentod.compression=zstd.copies=2optional (halbiert Kapazitaet, gibt etwas Self-Heal) - eher skippen, stattdessen SMART ueberwachen und Daten als ersetzbar betrachten.Fazit
Fuer Jellyfin-Medien brauchbar. Fuer alles Wichtige (Configs, State, Backups) NICHT - das gehoert auf zuverlaessigen Storage bzw. PBS.
Plattenlayout final geklaert
Damit gilt:
media-Dataset auf die HDD.Einordnung SSD
SanDisk Ultra = Consumer-SATA-SSD (DRAM-less TLC), keine Enterprise-/PLP-Platte. Fuer einen Single-Node-Homelab-Boot voellig ok. Kein Cluster -> moderate Schreiblast, haelt jahrelang. Wer die Schreiblast minimal halten will: ext4/LVM statt ZFS-on-root fuers System (etwas weniger Write-Amplification) - ZFS-on-root ginge aber auch.
Offener Punkt "Boot-Platte" ist damit geschlossen. Verbleibend offen: nur noch "HA = Home Assistant?" bestaetigen.
Entscheidung: HA (Home Assistant) faellt RAUS
Grund: ioBroker (CT 143, pve-mu-3) ist bereits als zentraler Smart-Home-Hub im Einsatz (inkl. InfluxDB + Grafana-Dashboards fuer Solar/Heizung/E3DC/Tesla). HA waere ~90% redundant -> doppelte Wartung + moegliche Geraete-Konflikte (zwei Hubs pollen dieselben Geraete). Kein ausreichender Mehrwert. Home Assistant wird daher NICHT auf dem neuen Host installiert.
(Falls spaeter doch lokale Sprachsteuerung gewuenscht: separat bewerten und dann ioBroker<->HA per MQTT bridgen statt duplizieren - nicht Teil dieses Plans.)
Plan-Scope steht damit fest
Gestrichen: Nextcloud, HA.
Enthalten: ZFS-Pool (Medien, ST2000DM001), GPU-Sharing per LXC (3080), Jellyfin-LXC (NVENC), Uebersetzungs-LXC (#103), Cloudflared, Monitoring, PBS-Backup, Doku-Migration.
Plattenlayout: SanDisk Ultra 250GB SSD (OS+LXC) + ST2000DM001 2TB HDD (Medien).
Alle offenen Punkte geklaert. Wartet nur noch auf: Host installiert + IP + root.
KORREKTUR Plattenlayout: 2x 2TB als ZFS-MIRROR (RAID1)
Geplant war von Anfang an 2x 2TB im ZFS-Mirror (RAID1) zur Ausfallsicherheit - NICHT eine Einzelplatte. Die vorherigen Einzelplatten-Kommentare (#269/#270) sind damit ueberholt.
Finales Layout
Wichtige Caveats
smartctl -t longauf BEIDEN vor dem Bau, regelmaessigezpool scrub(z.B. woechentlich) +smartd-Alarm.Pool-Anlage
zpool create -o ashift=12 tank mirror <disk1> <disk2>,compression=zstd, Datasetmediafuer Jellyfin. Backups weiterhin auf pbs-muldenstein (nicht lokal).Freigabe: beide Mirror-Platten duerfen platt gemacht werden
Bestaetigt: Die zwei 2TB-Platten (aktuell USB D:/E:) sind die ZFS-Mirror-Platten und duerfen komplett geloescht werden - kein Backup der Inhalte noetig. Datenverlust-Caveat aus #273 ist damit erledigt.
Bau-Reihenfolge:
smartctl -t longauf beiden, Ergebnis abwarten (auf ST2000DM001-Schwaechen achten).zpool create -o ashift=12 tank mirror <disk1> <disk2>, dannzfs set compression=zstd tank, Datasettank/media.zpool scrub+smartd-Alarm einrichten.Backup-Anbindung an pbs-muldenstein
Neuer Host sichert auf das bestehende pbs-nvme (Muldenstein) - keine lokalen Backups auf dem Host.
Zieldaten
100.99.139.22(Port 8007)nvme-pool(~1,7 TB frei)jellyfin-host(trennt Snapshots sauber)Einrichtung auf dem neuen Host
100.99.139.22erreichbar ist).proxmox-backup-manager cert info | grep Fingerprint- oder beim Hinzufuegen aus der GUI uebernehmen.pvesm add pbs pbs-muldenstein --server 100.99.139.22 --datastore nvme-pool --username <user@pbs> --password <...> --fingerprint <FP> --namespace jellyfin-hostsnapshot.nvme-poolvoll.mailnotificationnur sinnvoll wenn echte Empfaenger-Adresse hinterlegt ist - sonst bleibt ein fehlgeschlagenes Backup unbemerkt).Was NICHT gesichert wird
tank/media, Jellyfin-Filme) ist bewusst nicht im Backup - ersetzbare Medien, wuerde nur den Datastore fluten. Gesichert werden die LXC-Container (Konfig/System), nicht die Mediathek.Verifikation nach erstem Lauf
proxmox-backup-client snapshot listbzw. PBS-GUI.Monitoring / Logging: in das zentrale Loki einbinden
Der neue Host darf KEINE Insel sein - Logs und Metriken muessen ins bestehende zentrale Monitoring, sonst bleibt wieder etwas monatelang unbemerkt (Lehre aus #105).
Bestehende Architektur
http://<CT110-Tailscale-IP>:3100/loki/api/v1/push(genaue IP aus CT-999-Doku ziehen)Einzurichten auf dem neuen Host
/var/log/syslog,journal, vzdump/Backup-Logs an Loki.nvidia-gpu-exporter(oderdcgm-exporter) fuer die RTX 3080 - Auslastung/Temperatur/VRAM, wichtig weil GPU zwischen Jellyfin (NVENC/NVDEC) und Uebersetzung (CUDA) geteilt wird.host=<neuer-host>,service=jellyfin|translate) damit in Grafana filterbar.Alerts (damit Ausfaelle auffallen)
zpool status) -> Alert.Hinweis
Die genaue CT110-Tailscale-IP + ob Promtail oder Grafana Alloy als Agent Standard ist, vor dem Einrichten aus der CT-999-Doku (
container/ct-110-*.md) bzw. von CT151 als Vorlage uebernehmen.Monitoring / Logging: in das zentrale Loki einbinden
Der neue Host darf KEINE Insel sein - Logs und Metriken muessen ins bestehende zentrale Monitoring, sonst bleibt wieder etwas monatelang unbemerkt (Lehre aus #105).
Bestehende Architektur
http://<CT110-Tailscale-IP>:3100/loki/api/v1/push(genaue IP aus CT-999-Doku ziehen)Einzurichten
/var/log/syslog, journal, vzdump/Backup-Logs an Loki.nvidia-gpu-exporter(oderdcgm-exporter) fuer die RTX 3080 - Auslastung/Temp/VRAM, wichtig weil GPU zwischen Jellyfin (NVENC/NVDEC) und Uebersetzung (CUDA) geteilt wird.host=<neuer-host>,service=jellyfin|translate).Alerts
zpool status)Genaue CT110-IP + ob Promtail oder Grafana Alloy Standard ist, vor dem Einrichten aus CT-999-Doku (
container/ct-110-*.md) / CT151 als Vorlage.Tailscale in ALLE CTs (nicht nur auf den Host)
Jede CT des neuen Hosts kommt direkt ins Tailnet - eigene Tailscale-IP pro Container. Vorteil: Erreichbarkeit ohne DNAT/Port-Forwarding-Gefrickel, einheitlich mit dem restlichen Homelab, und auch das PBS (
100.99.139.22) + Loki sind direkt erreichbar.Technischer Stolperstein bei LXC
Tailscale braucht in der CT entweder ein
/dev/net/tun-Device oder den Userspace-Modus:Variante A - tun-Device durchreichen (empfohlen, volle Performance):
In die CT-Config (
/etc/pve/lxc/<id>.conf) auf dem Host:Voraussetzung:
tun-Modul auf dem Host geladen (modprobe tun, in/etc/modules). Funktioniert auch fuer unprivilegierte CTs.Variante B - Userspace-Networking (ohne tun):
tailscaled --tun=userspace-networking- wie bereits bei immo-tracker im Einsatz. Einfacher, aber langsamer; nur wenn tun-Bind nicht moeglich.Pro CT
tailscale up --hostname=<sprechender-name>(z.B.jellyfin,translate).Hinweis
Tailscale auf dem Host ist ohnehin Pflicht (fuer PBS-Backup, siehe #275). Zusaetzlich pro CT wie hier beschrieben.
Arbeitsteilung: Cline baut, Aufsicht verifiziert
Rollen
Zugang fuer Cline
1. SSH-Key (Rueckgrat, deckt 100% der Arbeit):
ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\proxmox_cline -N '""'~/.ssh/authorized_keysauf dem neuen Host.ssh.exeist bereits gesetzt (sonst Pipe-Haenger).2. canvrno/ProxmoxMCP (Cline-nativ, fuer strukturierte CT-Ops + Status-Aufsicht):
pveum user token add root@pam cline-mcp --privsep 0(Homelab-einfach) bzw. dedizierter User/Role fuer Least-Privilege.cline_mcp_settings.jsoneintragen (Windows:.venv\Scripts\python.exe). ENV:PROXMOX_HOST=LAN-IP,PROXMOX_USER=root@pam,PROXMOX_TOKEN_NAME=cline-mcp,PROXMOX_TOKEN_VALUE=,PROXMOX_PORT=8006,PROXMOX_VERIFY_SSL=false.STOPP-PUNKTE (Cline darf NICHT eigenmaechtig durchlaufen)
Bei diesen Schritten erst Plan/Befehl vorlegen, Freigabe abwarten, dann ausfuehren:
zpool create(ZFS-Mirror) - loescht die Platten unwiderruflich.Diese Regel kommt beim Bau zusaetzlich in die
.clinerulesauf dem KI-Server.Verifikation durch Aufsicht (nach jeder Phase, per SSH)
zpool status|nvidia-smi|tailscale status| PBS-Snapshot vorhanden |pct list/ CT-Health.Entscheidungen: RAM-Ausbau + Remote-Zugang
RAM (groesstes Problem, wird aufgeruestet)
Aktuell 16 GB - zu knapp (ZFS-ARC bis 50% + Jellyfin + Uebersetzungsmodell + LXCs).
Empfehlung: 2x 32 GB DDR4-3200 CL16 (= 64 GB), NICHT alle 4 Baenke bestuecken.
zfs_arc_max~8-12 GB klemmen.Remote-/Web-Zugang: Cloudflare-Tunnel (bewusst gewaehlt)
Nutzer kennt die CF-ToS-Thematik (Video ueber CDN) und nutzt CF-Tunnel bewusst, am liebsten im LAN an CF-Tunnel. Entscheidung: Cloudflared bleibt fuer den Zugang. Tailscale ist zusaetzlich vorhanden (alle CTs) als Fallback/Direktweg.
KORREKTUR GPU-Architektur: iGPU fuer Jellyfin, RTX 3080 nur fuer Uebersetzung
Loest das fruehere GPU-Sharing-Design ab. Statt die 3080 zwischen Jellyfin und Uebersetzung zu teilen, wird sauber getrennt:
/dev/dri/renderD128)Warum besser
Korrektur zur frueheren UMA-Empfehlung
Da die iGPU jetzt ARBEITET: UMA-Buffer NICHT minimal, sondern ~1-2 GB geben. Bei 64 GB RAM vernachlaessigbar.
Setup-Hinweise
/dev/dri/renderD128in die Jellyfin-LXC, die 3080 (NVIDIA) in die Uebersetzungs-LXC.RAM-Entscheidung final: 4x 16 GB = 64 GB (Server-Kontext)
Korrigiert die fruehere 2x32-Empfehlung. Fuer DIESEN Server ist 4x 16 GB voellig ok.
Warum die '4-Baenke-Warnung' hier NICHT zaehlt
Die Regel 'nicht alle 4 Baenke fuellen' ist ein Gamer-/Enthusiasten-Thema (FCLK/RAM-Takt fuer Frames). Dieser Host ist ein Server: Jellyfin-Transcoding laeuft auf der iGPU, ZFS + LXCs sind nicht speicherbandbreiten-empfindlich. Ob RAM mit 3200 oder 2667 laeuft, ist hier praktisch irrelevant. Der einzige reale Nachteil der 4 Baenke (Downclock) faellt damit weg.
Vorgaben
Kontext
DDR4 ist 2026 am Auslaufen (Hersteller auf DDR5/HBM umgestiegen) -> Preise hoch (~450 EUR fuer 64 GB). 32-GB-Module haben Knappheitsaufpreis, daher kann 4x16 sogar guenstiger als 2x32 sein.
ZFS-ARC
Mit 64 GB ARC nicht zwingend klemmen noetig; bei Bedarf
zfs_arc_maxmoderat setzen.RAM-Entscheidung final (aktualisiert): erstmal bei 16 GB bleiben
DDR4 ist zu teuer (~450 EUR fuer 64 GB) -> Start mit den vorhandenen 16 GB, Upgrade spaeter.
Warum 16 GB hier machbar ist
Die schweren Brocken (Whisper/MT/TTS) liegen im VRAM der 3080, Jellyfin transcodet auf der iGPU. Der System-RAM muss also wenig stemmen: Host + ZFS-ARC + ein paar kleine LXCs.
PFLICHT bei 16 GB
zfs_arc_maxhart klemmen auf ~2-3 GB (sonst greift ZFS per Default bis 8 GB als Cache -> wird eng). Medien-Pool braucht keinen grossen ARC.Setzen:
/etc/modprobe.d/zfs.conf->options zfs zfs_arc_max=3221225472(3 GB), dannupdate-initramfs -u+ reboot.Upgrade-Pfad (spaeter)
Bei Bedarf auf matched 4x 16 GB = 64 GB wechseln (siehe #286: Server-Kontext, Stabilitaet vor Takt). Vorhandene 16 GB werden dann ersetzt, nicht ergaenzt (Kit-Mischung vermeiden).
Plattenlayout aktualisiert: NVMe als Boot/System
Vorhandene Kingston NV3 PCIe-4.0 M.2 NVMe kommt rein - als Boot/OS/LXC-rootfs statt der SanDisk-SATA-SSD.
Finales Layout (aktualisiert)
Wichtige Einschraenkung: 5600G = PCIe 3.0
Der 5600G (Cezanne-APU) kann nur PCIe 3.0, nicht 4.0. Die NV3 (4.0) laeuft also auf PCIe-3.0-Tempo (~3500 MB/s) statt ~6000. Kein Problem - immer noch ~6x schneller als SATA (550 MB/s); fuer einen Server irrelevant. (Gilt analog fuer die 3080: laeuft PCIe 3.0 x16, fuer den Workload ok.)
SanDisk 250 GB SATA-SSD (freigeworden)
Sinnvoll: Scratch/Downloads/Transcode-Temp (ungesichert) oder Cold Spare. NICHT als ZFS L2ARC/SLOG - bei 16 GB RAM kontraproduktiv (L2ARC frisst RAM zum Indizieren), Medien-Pool braucht kein SLOG.
Hinweis
Boot/System ist weiterhin Single-Disk (kein Mirror) - CT-Configs liegen via PBS-Backup sicher; Recovery = Proxmox neu + Restore. NV3-Kapazitaet noch zu klaeren (500GB/1TB/2TB) fuer LXC-rootfs-Dimensionierung.
NVMe-Aufteilung: 500 GB (Boot/System)
Kingston NV3 = 500 GB - fuer Boot/OS/LXC-rootfs mehr als ausreichend.
Aufteilung (Proxmox-Standard, LVM-thin)
/)local-lvmThin-PoolBei 5-8 Containern a 8-30 GB bleibt locker 60-70% frei.
Dateisystem: ext4/LVM-thin (NICHT ZFS-on-root)
Bei 16 GB RAM bewusst kein ZFS fuer den Boot-Datentraeger - ein zweiter ZFS-Pool wuerde zusaetzlich ARC/RAM fressen. ZFS bleibt nur fuer den Medien-Mirror. Boot-NVMe = Proxmox-Default ext4/LVM-thin.
Synergie mit der freien SanDisk
Jellyfin-Transcode-Temp + Downloads auf die SanDisk-SATA-SSD, nicht auf die NVMe. Transcoding ist schreibintensiv/ephemer -> schont die NVMe-Schreibzyklen, SanDisk ist schnell genug und ersetzbar.
Rollenverteilung Datentraeger final
Phase-A-Detail: Proxmox-Install mit NUR der NVMe angesteckt
Waehrend der Proxmox-Installation SanDisk UND beide 2-TB-Platten physisch abklemmen - nur die NVMe dran lassen.
Warum
Ablauf
Wichtig fuer
zpool create/dev/disk/by-id/...verwenden, NICHT/dev/sdX- sdX-Namen koennen sich nach Umstecken verschieben, by-id ist stabil (ZFS-Best-Practice).Medien-Strategie final: lokaler ZFS-Mirror + Sync (NICHT live von SMB)
Entscheidender Kontext: Der Samba-Medienserver haengt an USB-Platten, die wiederholt eingeschlafen sind / SMB nicht erreichbar - laeuft jetzt, aber 'nicht zu 100%'. Mediathek aktuell 1,6 TB.
Entscheidung
rsyncvom Medienserver (fehlertolerant, geplant) holt neue Filme, wenn die Quelle erreichbar ist. Jellyfin liest lokal, merkt nichts vom Quell-Zustand.Kapazitaets-Warnung
1,6 TB auf 2 TB = ~80 % voll = ZFS-Komfortgrenze. Funktioniert fuer Medien noch, aber kaum Wachstum. Bei weiterem Wachstum groessere Platten einplanen.
Zukunftsoption
Dieser Host mit zuverlaessigem Mirror koennte mittelfristig die Primaerquelle werden, der USB-Bastel-Server das Backup (Rollentausch). Spaeter zu pruefen.
Datentraeger-Rollen (aktualisiert)
KORREKTUR: Medien-Mirror = mdadm RAID1 + ext4 (ZFS raus, spart RAM)
ZFS kostet RAM (ARC) - bei 16 GB ein echter Posten. Loesung: Redundanz ohne ZFS.
Entscheidung
2x 2 TB als Linux mdadm RAID1 + ext4 statt ZFS-Mirror.
zfs_arc_max-Klemmen entfaellt, RAM-Druck an der Stelle weg.Was wegfaellt (fuer diesen Fall wertlos)
ZFS-Checksums/Self-Healing, Snapshots, Kompression - Medien sind ersetzbar, Video ist schon komprimiert (ZFS-Compression ~0 Nutzen), Snapshots fuer Mediathek unnoetig.
Was bleibt
Redundanz: ueberlebt einen Plattenausfall. Genau das wird gebraucht, weil die SMB-Quelle unzuverlaessig ist.
Monitoring-Aequivalente (statt zpool status / scrub)
mdadm --monitor-> Alarm bei degraded Array (in Loki)checkarray(Scrub-Aequivalent von mdraid)Anlage
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/disk/by-id/<d1> /dev/disk/by-id/<d2>(by-id!), dannmkfs.ext4 /dev/md0, mounten, Jellyfin liest hier; Sync per rsync vom Medienserver. Bleibt Stopp-Punkt (loescht Platten).Datentraeger-Rollen final
System ist damit komplett ZFS-frei.
FINAL: Einzelplatte 1x 2 TB ext4 (kein RAID, kein ZFS)
Entscheidung: eine Platte reicht. RAID1 ist fuer eine temporaere, bald zu ersetzende Platte, die nur eine Kopie haelt (Master liegt auf dem Medienserver), Over-Engineering.
Setup
Bewusst akzeptierter Trade-off
Platte stirbt -> lokale Kopie weg -> 1,6 TB neu vom SMB ziehen (laestig, aber kein Datenverlust, Master bleibt).
Kapazitaet unkritisch
Auf ext4 ist die 80%-Grenze irrelevant (war nur ZFS-Thema) - laeuft bis ~95% problemlos. 1,6 TB auf 2 TB ok. Bei Wachstum gegen groessere Platte tauschen (so ohnehin geplant).
Optional: 2. Platte als Cold Spare
Zweite 2-TB-Platte in die Schublade als Cold Spare - stirbt die aktive ST2000DM001, Spare rein + re-syncen, ohne erst kaufen zu muessen. Null Betriebsaufwand. Optional.
Datentraeger-Rollen final
System komplett ZFS-frei UND RAID-frei. Maximal einfach.
KORREKTUR Storage (ueberschreibt #291/#292/#293) - Medien liegen auf bestehendem RAID, NICHT lokal
Wichtige Klarstellung vom Nutzer + Supervisor-Verifikation (14.06.2026, 20:00). Die gesamte vorherige Storage-Saga (lokale 2-TB-Platte, mdadm, ZFS, ext4, rsync-Kopie) ging von einer falschen Annahme aus und ist damit hinfaellig.
Tatsaechliche Lage (verifiziert)
optiplex2(192.168.178.170) haengt und dort als SMB-ShareMedien("Medienfestplatte fuer Jellyfin") bereitgestellt wird.Filme zum nachbearbeiten,KI Modelle..keepalive(heute aktualisiert) -> gegen das alte USB-Einschlaf-Problem laeuft bereits ein Keepalive./mnt/nas,/srv/media->//192.168.178.170/Medien).Entscheidung / Plan (fuer spaeter)
Das USB-Gehaeuse wird direkt an den neuen Jellyfin-Host umgesteckt (USB-Kabel von optiplex2 ab, an den neuen Server dran). Dann liest Jellyfin lokal statt uebers Netz - einfachste Loesung, kein lokaler Kopier-/Sync-Schritt noetig.
Bei Anschluss am neuen Host (Supervisor, read-only, VOR jeglichem Mount):
lsblk-> ein Device = Hardware-RAID; zwei Devices = JBOD.ro,_netdev,iocharset=utf8,x-systemd.automount), Jellyfin-Bibliotheken auf die Unterordner zeigen.WICHTIGER HAKEN beim Umstecken (Abhaengigkeiten brechen!)
Auf genau dieser Platte liegen nicht nur Filme. Wird sie von optiplex2 abgezogen, brechen weg:
KI Modelle-> wird von CT-146 (model-library) per SMB gemountet (//192.168.178.170/Medien/KI Modelle->/mnt/ki-modelle).Filme zum nachbearbeiten-> Ziel des SaveTV-Sync (stuendlicher Cron vom alten Jellyfin-Host bzw. CT 116-Pipeline).-> Vor/parallel zum Umstecken klaeren: Sollen diese beiden Funktionen mit auf den neuen Host umziehen (neuer Share/Mount-Pfad) oder werden sie eingestellt? Sonst laufen CT-146 und SaveTV ins Leere.
Status
Phase D+E (GPU) ABGESCHLOSSEN + Lehre (Supervisor-verifiziert, 14.06.2026 ~21:40)
NVIDIA-Treiber laeuft, GPU-Trennung steht. War der zaeheste Teil - mehrere Sackgassen, daher hier die Lehre festgehalten.
Endstand (unabhaengig verifiziert)
nvidia-smi/dev/nvidia-uvmvorhanden ✓nvidia/580.126.09, 6.14.11-9-pve: installed6.14.11-9-pve- gepinnt (proxmox-boot-tool kernel pin)/dev/dri/renderD128(by-path pci-0000:30:00.0-render)/dev/nvidia0+/dev/dri/renderD129(CUDA)LEHRE - fuer den naechsten GPU-Host nicht wiederholen
zone_device_page_init/__vm_flags/in_irq- Kernel-APIs neuer als alle aktuellen Treiber).-> VOR NVIDIA-Install auf stabilen 6.14.11-9-pve wechseln (
apt install proxmox-kernel-6.14), booten, dann PINNEN (proxmox-boot-tool kernel pin 6.14.11-9-pve). Ohne Pin bootet das naechsteapt upgradewieder 7.0 -> GPU tot.--no-unified-memory(vom Bauenden zwischenzeitlich als Workaround genutzt) ist Selbstbetrug: ohne uvm kein CUDA -> Uebersetzungs-Pipeline startet gar nicht. uvm ist Pflicht.readlink -f /dev/dri/by-path/pci-0000:30:00.0-renderpruefen, nicht hardcoden. -> Jellyfin auf renderD128.--silent --dkms --kernel-module-type=open --no-x-check(Debian-non-free-Paket war zu alt).Naechste Schritte
Nutzer-Entscheidungen 15.06.2026 (Supervisor-dokumentiert) + Phase B verifiziert
Supervisor-Abnahme Phase B (unabhaengig per SSH gegengeprueft, nicht Eigenbericht)
Alles bestaetigt: pve-jervais, PVE 9.2.3, Kernel 6.14.11-9-pve gepinnt, Tailscale 100.67.193.113, NVIDIA 580.126.09 (3080, CUDA 13.0, nvidia0/ctl/uvm da), DKMS installed, iGPU renderD128 (pci 30:00.0) / 3080 renderD129 (pci 10:00.0), authorized_keys=3 (KI-Server ed25519 + pve-hetzner rsa + root@pve), Repos no-subscription, NTP Europe/Berlin, kein VFIO in cmdline. Keine Abweichung.
3 Entscheidungen vom Nutzer
1. Jellyfin bauen - mit ALLEN bisherigen Funktionen, Medien wieder als Samba im LAN
Medienim LAN -> ersetzt die bisherige Freigabe von optiplex2.Medien+ Gast/ro wie bisher beibehalten, damit Clients nur die IP wechseln.2. SaveTV-Projekt loeschen (hat nie zuverlaessig funktioniert)
savetv-web.service(Port 8765/extern 9443),savetv_extra_routes.py-Hook im Git-Repohomelab-brain/homelab-ai-bot/, zugehoerige Cron-Jobs, Staging-OrdnerFilme zum nachbearbeiten.3. Funktion "KI Modelle sammeln" zieht um
//192.168.178.170/Medien/KI Modelle->/mnt/ki-modelle. Da das Gehaeuse auf pve-jervais umzieht, muss dieser Mount auf die neue Samba-Freigabe auf pve-jervais (.40) umgestellt werden (PfadKI Modellebleibt auf der Platte). Daten ziehen mit dem Gehaeuse mit, nur das Mount-Ziel aendert sich.KRITISCH vor dem physischen Umstecken (.170 -> .40)
Der SMB-Server-Wechsel von 192.168.178.170 -> 192.168.178.40 bricht ALLE Clients, die
\\192.168.178.170\Medienmounten. Vor dem Abziehen ENUMERIEREN + umpunkten:optiplex2-Share aktuell: Samba 4.17.12, Share
Medien("Medienfestplatte fuer Jellyfin"), Gast/kein PW, ~14,9 TB (~11 TB frei).Rollen
Cline baut (Jellyfin-LXC, Samba-Re-Export, SaveTV-Removal, CT146-Ummount). Supervisor verifiziert nach jeder Phase + ueberwacht. Physisches Umstecken des Gehaeuses = Nutzer.
Ausfuehrungsreihenfolge HEUTE (Nutzer-Entscheidung 15.06.2026)
Jellyfin wird ZUERST gebaut, Platten-Umzug erst danach. Staged, damit der Medien-Cutover vom funktionierenden Jellyfin entkoppelt ist.
Reihenfolge
savetv_sync.pyauskommentieren) - vor allem anderen./media). Beim spaeteren Platten-Umzug wird NUR das Backing an genau diesem Pfad von CIFS(.170) auf lokalen bind-mount getauscht -> Library-DB bleibt gueltig, kein Re-Scan/Verlust von Watch-State.Medien, Gast/ro) -> LAN./mnt/ki-modelle), KI-Server Laufwerk Z:. (SaveTV entfaellt, alt-JF wird abgeloest.).170-Clients (vor Umzug bekannt)
alt-JF .149 (3x CIFS /mnt/nas,/mnt/nas_filme,/srv/media) | CT146 /mnt/ki-modelle | KI-Server Z: | SaveTV (gel.). Keine weiteren in der Doku.
Build-Brief Jellyfin-Migration fuer Cline (Quellen verifiziert 15.06.2026)
Zugang Quelle (.149)
Tailscale-SSH (kein Passwort, dokumentiert): von einem Tailnet-Node
ssh root@100.77.105.3-> einmalige Browser-Freigabe (login.tailscale.com). Passwort root/astral66 + michael/Sprint-99 funktionieren NICHT.Quelle auf .149 (Docker jellyfin/jellyfin:10.9.11)
/opt/jellyfin/config-> Container/config/opt/jellyfin/cache/mnt/nas(CIFS //192.168.178.170/Medien) -> Container/mediaZiel: Jellyfin-LXC auf pve-jervais
/opt/jellyfin/configvon .149 -> neues/config(rsync via Tailscale). Cache weglassen./mediamounten - vorerst CIFS//192.168.178.170/Medien(Gast, vers=3.0,ro). Beim spaeteren Platten-Umzug nur das Backing hinter/mediaauf lokalen bind-mount tauschen -> Library-DB bleibt gueltig.vaapiauf Intel-iGPU; Geraet bleibt renderD128, aber AMD-Treiber (mesa-va-drivers) + Decode-Codecs gegentesten. Nicht als "laeuft schon" annehmen.Supervisor-Verifikation danach (auf .40)
LXC laeuft | Login
Orbitalo/Astral1966| Nutzer + Watch-State vorhanden | Bibliotheken sehen/media| HW-Transcoding erzeugt Last auf renderD128 (AMD) | Cloudflared erreichbar.Hinweis
Nextcloud auf .149 = ungenutzt (letzter Login 19.12.2025, 54 MB, nur Default-Vorlagen) -> wird geloescht, nicht migriert. HA (
/home/homeassistant, 339 MB) + Zigbee-Dongle = spaeterer separater Umzug, .149 vorerst NICHT abschalten.⚠️ STOPP vor config-Copy - 2 Supervisor-Flags (CT200, 15.06 17:08)
CT200 jellyfin laeuft (frisch, 10.11.11), Medien sichtbar. BEVOR die alte config von .149 kopiert wird, bitte beide Punkte klaeren - sonst bricht die Migration:
1. Mount-Pfad:
/mnt/media!= altes/mediaAltes Jellyfin (.149) hatte Medien im Container unter
/media. CT200 mountet aktuell unter/mnt/media. Die migrierte Library-DB referenziert aber/media/...-> Bibliotheken laufen ins Leere.Fix: Medien im Container an
/mediamounten (Mount-Entry anpassen:/mnt/media mnt/media->/media media), ODER nach dem Copy alle Library-Pfade/media->/mnt/mediaumschreiben. Erstes ist sauberer.2. Versionssprung 10.9.11 -> 10.11.11 = kein blanker File-Copy!
Zwischen 10.9 und 10.11 hat Jellyfin das DB-Schema umgebaut (10.10/10.11 haben die DBs zusammengefuehrt, neue jellyfin.db). Ein rsync der alten 10.9-
/configauf die frische 10.11-Instanz kann die DB zerschiessen / Watch-State verlieren.Empfehlung: entweder erst 10.9.x installieren -> config kopieren -> starten (DB migriert sauber hoch) -> dann auf 10.11 updaten, oder bewusst Bibliotheken neu scannen und nur Nutzer/Settings uebernehmen. Reiner Copy 10.9->10.11 ist riskant.
Mapping Docker -> deb beachten
Quelle ist Docker (alles in
/config). Ziel ist das deb-Paket mit getrennten Pfaden: config ->/etc/jellyfin, data (DBs, Library) ->/var/lib/jellyfin, plugins/metadata entsprechend. Nicht 1:1/config-> ein Verzeichnis.Supervisor verifiziert nach dem Copy: Nutzer
Orbitaloda, Watch-State erhalten, Bibliotheken sehen die Medien, VAAPI-Last auf renderD128.❌ Supervisor-Verifikation CT200: Migration NICHT angewendet + VAAPI defekt (15.06 17:45)
Unabhaengig per SSH geprueft. Der Eigenbericht "Config migriert / Bibliotheken auf /mnt/media" stimmt nicht mit dem Live-Zustand ueberein.
1. Config-Migration ist NICHT angekommen (nur gestaged)
Die Live-Instanz ist eine leere Erstinstallation:
GET /System/Info/Public->StartupWizardCompleted: false, neue ServerIddb6add1a.../var/lib/jellyfinnur 580K,jellyfin.dbunveraendert (475K, mtime 15:28 = Frischinstall)root/default/leer -> KEINE Bibliotheken, KEINE NutzerDie Quelle liegt korrekt im Staging
/var/lib/vz/jf_migrate(intakt):data/library.db36,9 MB,data/playback_reporting.db,root/default/= Filme + Sammlungen. -> Es wurde also gestaged, aber nie in/var/lib/jellyfin+/etc/jellyfinimportiert.ToDo Cline: Staging mit korrektem deb-Mapping einspielen (staging/data->/var/lib/jellyfin/data, staging/config->/etc/jellyfin, metadata/plugins/root entsprechend), Jellyfin stoppen waehrend Copy. Achtung Versionssprung: Quelle hat
library.db(10.9-Schema) -> 10.11 muss die DB-Migration beim Start real durchlaufen (sonst leere Bibliothek).2. VAAPI-HW-Transcoding ist NICHT funktionsfaehig (2 Ursachen)
HardwareAccelerationType = none(nichtvaapi) -> HW-Transcoding ist schlicht aus.renderD128= root:render (GID 993), aber CT200 hat keine idmap -> im Container erscheint das Device als Besitzer 65534 (overflow). Derjellyfin-User ist in Container-Grupperender=GID 992, hat damit keinen Zugriff auf das Device. Deshalb scheitert auchvainfo.ToDo Cline: idmap in
/etc/pve/lxc/200.confsetzen, die die Host-GID 993 in den Container mappt (bzw. Proxmoxdev0: /dev/dri/renderD128,gid=...), Container-render-GID angleichen; danach encoding.xml aufvaapi(Device renderD128). Erst dann macht der Transcode-Test Sinn.Fazit
Stand jetzt: leere Jellyfin-Instanz, kein HW-Transcoding. Schritt 4 (Platte umstecken) noch NICHT freigeben - erst Migration real einspielen + VAAPI fixen, dann verifiziere ich erneut (Nutzer Orbitalo, Watch-State, Bibliotheken sehen Medien, echte GPU-Last).
✅ Supervisor-Verifikation CT200: Jellyfin-Migration BESTANDEN (15.06 18:00)
Alle Punkte unabhaengig per SSH geprueft – jetzt sauber:
Migration / Daten
StartupWizardCompleted: true, config 9,4 G,jellyfin.db48,7 MB (library.db → jellyfin.db migriert, 10.9→10.11 durchgelaufen)UserData= 506 Eintraege/media/...-Pfad in der DBPfad-Fix (war Show-Stopper)
mnt/mediaauf/mediakorrigiert → Bibliothekspfade (/media/Recorded TVetc.) loesen jetzt auf echte Dateien auf. CIFS//192.168.178.170/Medienist befuellt im Container sichtbar.VAAPI HW-Transcoding – FUNKTIONIERT (entgegen "vainfo scheitert")
jellyfin-User: Encoderh264_vaapi+scale_vaapi, 438 fps / 17,5x Echtzeit sustained → eindeutig Hardware.amdgpu@ PCI0000:30:00.0(AMD Vega), idmap GID 993 korrekt,jellyfinhat Device-Zugriff,encoding.xml=vaapi.gpu_busy_percent/amdgpu_pm_info GPU Loadzeigen 0 % – das ist ein Messartefakt (misst GFX-Engine, nicht den VCN-Video-Block). Der Durchsatz ist der Beweis.Fazit
Jellyfin auf CT200 ist voll funktionsfaehig (Nutzer, Watch-History, Bibliotheken mit Inhalt, HW-Transcoding). Schritt 4 (USB-RAID von .170 auf .40 umstecken) ist jetzt freigegeben. Danach: Medien-Backing am selben Pfad
/mediavon CIFS(.170) auf lokalen bind-mount umstellen (DB bleibt gueltig), dann Samba-Re-Export.Phase J (Backup/PBS) — abgeschlossen & extern verifiziert (16.06.2026)
CT200 (Jellyfin) auf pve-jervais wird jetzt korrekt nach PBS gesichert. Supervisor-verifiziert (nicht nur "Worker meldet erfolgreich").
Endstand
pbs-nvmebackup@pbs!pve-jervais(kein root@pam) + Namespacejellyfin-host, Datastorenvme-pool(PBS 100.99.139.22)ct/2005,52 GiB im NSjellyfin-host,owner=backup@pbs!pve-jervais(per PBS-API gegengeprüft)jellyfin-daily, täglich 03:30, Retention keep-daily=7/keep-weekly=4/keep-monthly=6Korrekturen am ersten (fehlerhaften) Setup
Der erste Durchlauf des Workers war oberflächlich "erfolgreich", hatte aber drei Fehler, die im Supervisor-Review behoben wurden:
root@pamauf den Token umgestellt.jellyfin-host→ dort existieren bereits fremdect/200-Backups eines anderen Nodes; der Prune-Job (vmid 200) hätte diese mit weglöschen können. Storage auf Namespacejellyfin-hostumgestellt → Isolation/Prune-Kollision behoben.root@pam-Passwort auf pve-jervais (/tmp/setup_ct200_backup.py,fix_ct200_backup.py,backup_ct200_final.py— letzteres vom Worker nicht erwähnt) → gelöscht. Waren nie in Git/Forgejo (Tree + History geprüft), daher kein History-Scrub/keine Passwort-Rotation nötig (privates Repo, vom Nutzer so entschieden).Zusätzlich: verwaister Root-NS-Eintrag
ct/200(Fehlversuch von 10:36) gezielt entfernt; die 6 fremden Feb/März-Backups blieben unberührt.Kontext / Vorgeschichte
Dieser Schritt schließt an die .149-Abschaltung an (siehe #112). Alter Jellyfin-Host
debian-jellyfin-homeassistent(.149) ist stillgelegt; Jellyfin läuft auf CT200/pve-jervais.Offen (Nutzer, physisch)
OpenMemory + CT999-Doku aktualisiert.
Status-Abgleich 16.06.2026 (verifiziert auf pve-jervais)
Host
pve-jervais(Tailscale 100.67.193.113, LAN .40). Alle Punkte unten direkt auf dem Host geprueft, nicht aus dem Gedaechtnis./mnt/media(UUID 687B-C0E4, fstabnofail).zpool list= leer. Bewusst so, da grosse USB/exFAT-Platte uebernommen. -> Phase C gilt als erledigt in Variante exFAT.prometheus-node-exporterauf :9100,promtailauf :9080 -> Loki 100.109.206.43:3100. Offen nur: Scrape-/Health-Eintrag auf Prometheus-Seite (CT110) gegenpruefen.Architektur-Klarstellung (wichtig fuer kuenftige Sessions)
Der urspruengliche Plan sah NVENC auf der 3080 fuer Jellyfin vor. Real laeuft Jellyfin auf der AMD-iGPU (VAAPI). Das ist besser fuer das Gesamtziel: die 3080 bleibt zu 100 % fuer die Echtzeit-Uebersetzung (#103, CUDA) frei - keine NVENC/CUDA-Konkurrenz. GPU-Sharing der 3080 in LXC wird daher erst beim Bau der Uebersetzungs-Pipeline relevant.
Verbleibende offene Punkte
Fazit: Setup-Geruest (#107) ist bis auf die Uebersetzungs-Pipeline (Phase E NVIDIA-Teil + G) abgeschlossen. Naechster Schritt liegt in #103.
Update Phase E/G (16.06.2026)
Phase E (NVIDIA-LXC-Sharing): erledigt. Im Zuge des #103-Phase-0-Spikes wurde LXC CT201
jervais-translatemit RTX-3080-Passthrough gebaut;nvidia-smiim Container zeigt die 3080 (Treiber 580.126.09), fp16-Modelle liefen real auf der GPU (96-97 % Util). 3080-Sharing damit bewiesen.Phase G (Uebersetzungs-Pipeline): Richtungswechsel. Phase-0-Validierung ergab, dass Khmer-STT lokal (Whisper) unbrauchbar ist (CER 0.95). Entscheidung des Users: Hauptbedarf = Englisch->Deutsch, Khmer-lokal verworfen. EN->DE laeuft lokal problemlos. Details + Begruendung in #103.
Naechster Schritt fuer Phase G: EN->DE-Streaming-Pipeline auf CT201, Basis-Evaluierung von PolyTalk / audio-streaming-poc (faster-whisper + NLLB + Piper). Eigentlicher Restaufwand = Handy-App (Mikro -> Tailscale -> CT201 -> Ohr).