Proxmox: GPU sharing in LXC Containern

Warum GPU-Sharing mit LXC-Containern?

Wenn du einen Proxmox-Server mit einer GPU betreibst und verschiedene Dienste wie Ollama (für KI-Modelle), Plex (für Medien-Transcoding) oder Frigate (für Videoüberwachung) mit Hardware-Beschleunigung nutzen möchtest, stehst du vor einer wichtigen Entscheidung.

Die zwei Optionen:

  1. GPU-Passthrough zu einer VM: Funktioniert gut, aber die GPU kann nur an EINE einzige VM weitergegeben werden
  2. GPU-Sharing mit LXC-Containern: Mehrere Container können sich die GPU gleichzeitig teilen

Da die meisten von uns ihre Dienste isoliert voneinander betreiben möchten, ist Option 2 mit LXC-Containern oft die bessere Wahl. Der einzige „Nachteil“: Du musst LXC-Container statt VMs verwenden – was für die meisten Standalone-Dienste aber kein Problem darstellt.

Voraussetzungen

Bevor wir loslegen, stelle sicher, dass folgende Voraussetzungen erfüllt sind:

  • Proxmox VE 8.2+ oder 9.0 (empfohlen für Web-UI Device Passthrough)
  • Eine unterstützte GPU (NVIDIA, AMD oder Intel)
  • Root-Zugriff auf den Proxmox-Host
  • Grundkenntnisse in der Linux-Kommandozeile

💡 Neu in Proxmox VE 9.0: Die Version 9.0 (veröffentlicht im August 2025) basiert auf Debian 13 „Trixie“ mit Linux Kernel 6.14.8-2 und bringt LXC 6.0.4 mit verbesserter Ressourcenverwaltung und Cgroup v2-Integration. Die Web-UI Device Passthrough Funktion wurde bereits in Version 8.2.7 eingeführt und ist in Version 9.0 weiter optimiert.

Wichtiger Hinweis: Falls du bereits GPU-Passthrough für VMs konfiguriert hast (mit Blacklisting von Treibern etc.), musst du diese Änderungen rückgängig machen. LXC-Container benötigen funktionierende Treiber auf dem Host!

Moderne Methode: Web-UI Device Passthrough (Proxmox 8.2.7+)

Seit Proxmox VE 8.2.7 gibt es eine deutlich einfachere Methode für GPU-Passthrough zu LXC-Containern über die Web-Oberfläche. Diese Methode funktioniert sogar mit unprivilegierten Containern!

Schritt 1: GPU im Web-UI hinzufügen

  1. Wähle deinen Container in der Proxmox Web-UI aus
  2. Gehe zu Resources
  3. Klicke auf Add → Device Passthrough
  4. Gib den Device-Pfad ein (z.B. /dev/dri/card0 für Intel/AMD oder /dev/nvidia0 für NVIDIA)
  5. Klicke auf Advanced und setze:
    • Access Mode: 0666
    • GID: 104 (render group) für unprivilegierte Container
    • UID: Optional, je nach Anwendung

Diese Methode ersetzt die manuelle Konfiguration mit lxc.cgroup2.devices.allow und lxc.mount.entry Einträgen!

NVIDIA GPU Konfiguration

Schritt 1: NVIDIA-Treiber auf dem Host installieren

Zuerst müssen die NVIDIA-Treiber auf dem Proxmox-Host installiert werden. Lade den passenden Treiber von der NVIDIA-Website herunter.

# Vorhandene NVIDIA-Pakete entfernen (wichtig!)
apt remove --purge nvidia* libnvidia* libnvcuvid1

# Nouveau-Treiber blacklisten
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
update-initramfs -u

# System neustarten
reboot

# NVIDIA-Treiber installieren (Beispiel für Version 550.127.05)
wget https://us.download.nvidia.com/XFree86/Linux-x86_64/550.127.05/NVIDIA-Linux-x86_64-550.127.05.run
chmod +x NVIDIA-Linux-x86_64-550.127.05.run
./NVIDIA-Linux-x86_64-550.127.05.run --dkms

Schritt 2: GPU-Geräte identifizieren

Nach der Installation überprüfe die NVIDIA-Geräte:

# NVIDIA-Geräte anzeigen
ls -l /dev/nvidia*

# Ausgabe sollte etwa so aussehen:
crw-rw-rw- 1 root root 195,   0 Nov 25 10:00 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Nov 25 10:00 /dev/nvidiactl
crw-rw-rw- 1 root root 507,   0 Nov 25 10:00 /dev/nvidia-uvm
crw-rw-rw- 1 root root 507,   1 Nov 25 10:00 /dev/nvidia-uvm-tools

Schritt 3: Container konfigurieren

Option A: Web-UI Methode (empfohlen für Proxmox 8.2.7+/9.0)

Füge über Resources → Add → Device Passthrough folgende Geräte hinzu:

  • /dev/nvidia0 mit Mode: 0666
  • /dev/nvidiactl mit Mode: 0666
  • /dev/nvidia-uvm mit Mode: 0666
  • /dev/nvidia-uvm-tools mit Mode: 0666
  • /dev/nvidia-modeset mit Mode: 0666 (falls vorhanden)

Option B: Manuelle Methode (für ältere Versionen)

Bearbeite die Container-Konfiguration (ersetze 100 mit deiner Container-ID):

nano /etc/pve/lxc/100.conf

Füge folgende Zeilen hinzu (passe die Zahlen an deine Geräte an):

# NVIDIA GPU Support
lxc.cgroup2.devices.allow: c 195:* rwm
lxc.cgroup2.devices.allow: c 507:* rwm
lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm-tools dev/nvidia-uvm-tools none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-modeset dev/nvidia-modeset none bind,optional,create=file

Schritt 4: NVIDIA-Treiber im Container installieren

Starte den Container und installiere die gleiche Treiberversion:

# Im Container ausführen:
wget https://us.download.nvidia.com/XFree86/Linux-x86_64/550.127.05/NVIDIA-Linux-x86_64-550.127.05.run
chmod +x NVIDIA-Linux-x86_64-550.127.05.run
./NVIDIA-Linux-x86_64-550.127.05.run --no-kernel-module

Wichtig: Der Parameter --no-kernel-module ist essentiell, da der Container den Kernel des Hosts nutzt!

AMD GPU Konfiguration

AMD-GPUs sind besonders interessant für KI-Workloads, da Modelle wie die RX 7900 XTX mit 24GB VRAM ausgestattet sind – perfekt für große LLMs!

Schritt 1: Geräte überprüfen

# AMD GPU-Geräte anzeigen
ls -l /dev/dri
ls -l /dev/kfd

Schritt 2: Container konfigurieren (Web-UI Methode)

In Proxmox 8.2.7+ und 9.0:

  1. Wähle deinen Container aus
  2. Gehe zu Resources
  3. Klicke auf Add → Device Passthrough
  4. Füge folgende Geräte hinzu:
    • /dev/dri/card0 mit Mode: 0666, GID: 104 (render)
    • /dev/dri/renderD128 mit Mode: 0666, GID: 104
    • /dev/kfd mit Mode: 0666 (für ROCm-Support)

Der Vorteil: Diese Methode funktioniert auch perfekt mit unprivilegierten Containern!

Schritt 3: ROCm im Container installieren

# ROCm Repository hinzufügen (Ubuntu/Debian)
wget -q -O - https://repo.radeon.com/rocm/rocm.gpg.key | apt-key add -
echo 'deb [arch=amd64] https://repo.radeon.com/rocm/apt/debian/ ubuntu main' > /etc/apt/sources.list.d/rocm.list

# ROCm installieren
apt update
apt install rocm-dkms

Intel GPU Konfiguration

Intel-GPUs eignen sich hervorragend für Media-Transcoding mit Plex oder Jellyfin. Mit Intel VT-d können in Proxmox 8.2+ sogar bis zu 7 VMs die GPU teilen!

Schritt 1: Intel GPU-Unterstützung auf dem Host

# Intel Media Driver installieren
apt update
apt install intel-media-va-driver-non-free

Schritt 2: Container-Konfiguration (Web-UI Methode)

Füge über die Web-UI folgende Geräte hinzu:

  • /dev/dri/card0 mit Mode: 0666, GID: 104
  • /dev/dri/renderD128 mit Mode: 0666, GID: 104

Alternativ für die manuelle Methode in /etc/pve/lxc/100.conf:

# Intel GPU Support
lxc.cgroup2.devices.allow: c 226:* rwm
lxc.mount.entry: /dev/dri dev/dri none bind,optional,create=dir

Schritt 3: Gruppe im Container anpassen

# Im Container die render-Gruppe für den Benutzer hinzufügen
usermod -aG video,render plex  # Beispiel für Plex-User

Unprivilegierte Container – Die sichere Wahl

Mit der Web-UI Device Passthrough Funktion ist es jetzt viel einfacher, GPUs auch in unprivilegierten Containern zu nutzen:

  • Setze einfach die GID auf 104 (render group) in den Advanced Settings
  • Keine komplexen idmap-Konfigurationen mehr nötig
  • Funktioniert out-of-the-box mit den meisten Anwendungen

Dies löst das alte Sicherheitsproblem, bei dem privilegierte Container für einfache GPU-Passthrough benötigt wurden.

Verifizierung der GPU-Funktionalität

Für NVIDIA:

# Im Container ausführen:
nvidia-smi

# Sollte die GPU und aktuelle Auslastung anzeigen

Für AMD:

# ROCm-Info anzeigen
rocm-smi
rocminfo

Für Intel:

# Intel GPU-Tools installieren und testen
apt install intel-gpu-tools
intel_gpu_top

Praktische Anwendungsfälle

Ollama für lokale LLMs

Nach der GPU-Konfiguration kannst du Ollama einfach installieren:

# Ollama installieren
curl -fsSL https://ollama.com/install.sh | sh

# Modell herunterladen und starten
ollama run llama3.2

# GPU-Nutzung überprüfen
nvidia-smi  # sollte Ollama-Prozess zeigen

Plex Media Server mit Hardware-Transcoding

# Nach Plex-Installation Hardware-Transcoding aktivieren:
# 1. Plex Web-Interface öffnen
# 2. Einstellungen → Transcoder
# 3. "Use hardware acceleration when available" aktivieren

Jellyfin mit GPU-Beschleunigung

Jellyfin ist besonders beliebt für GPU-Transcoding in LXC-Containern:

# Jellyfin Installation
apt update
apt install jellyfin

# In Jellyfin Settings → Playback:
# Hardware acceleration: VAAPI (Intel/AMD) oder NVENC (NVIDIA)

Frigate für Videoüberwachung

In der Frigate-Konfiguration config.yml:

ffmpeg:
  hwaccel_args: preset-nvidia-h264  # für NVIDIA
  # oder
  hwaccel_args: preset-vaapi  # für Intel/AMD

Häufige Probleme und Lösungen

Problem: „NVIDIA-SMI has failed“

Lösung: Stelle sicher, dass die Treiberversionen auf Host und Container identisch sind!

Problem: Permission denied beim GPU-Zugriff

Lösung: Bei unprivilegierten Containern: Verwende die Web-UI und setze die GID auf 104 (render group).

Problem: HDR Tone Mapping funktioniert nicht (Intel)

Bekanntes Problem: Bei Intel GPUs in LXC-Containern kann HDR Tone Mapping in Plex problematisch sein. Hardware-Transcoding funktioniert aber weiterhin.

Problem: Container startet nicht nach GPU-Konfiguration

Lösung: Prüfe die Syntax in der Container-Config. Ein fehlendes Komma oder Leerzeichen kann den Start verhindern.

Proxmox VE 9.0 – Was ist neu?

Die im August 2025 veröffentlichte Version 9.0 bringt einige Verbesserungen für Container:

  • LXC 6.0.4: Verbesserte Ressourcenverwaltung und Sicherheitsisolation
  • Cgroup v2: Bessere Integration für moderne Container-Workloads
  • Kernel 6.14.8-2: Verbesserte GPU-Treiberunterstützung
  • SDN Fabric Support: Komplexere Netzwerkarchitekturen für Container-Cluster

Die Web-UI Device Passthrough Funktion wurde bereits in 8.2.7 eingeführt und ist in 9.0 weiter optimiert worden.

Wichtige Überlegungen zur Sicherheit

LXC-Container mit GPU-Zugriff haben erweiterte Rechte. Beachte folgende Punkte:

  • Unprivilegierte Container (empfohlen): Mit der Web-UI Device Passthrough Methode jetzt einfach umsetzbar
  • Privilegierte Container: Nur verwenden, wenn absolut notwendig
  • Verwende GPU-Sharing nur für vertrauenswürdige Workloads
  • Isoliere kritische Dienste in separaten Containern
  • Nutze die GID-Einstellungen für granulare Zugriffskontrolle

Performance-Tipps

  • Mehrere Container können die GPU gleichzeitig nutzen, aber die Performance wird geteilt
  • Für maximale Performance bei einzelnen Workloads: GPU-Passthrough zu einer VM verwenden
  • Überwache die GPU-Auslastung mit nvidia-smi, rocm-smi oder intel_gpu_top
  • Plane GPU-intensive Tasks zeitversetzt, wenn mehrere Dienste die GPU nutzen
  • Nutze die erweiterten Cgroup v2 Features in Proxmox 9.0 für bessere Ressourcenkontrolle

Fazit

GPU-Sharing mit LXC-Containern in Proxmox ist eine elegante Lösung, um Hardware-Beschleunigung für mehrere Dienste gleichzeitig bereitzustellen. Mit den Verbesserungen in Proxmox 8.2.7+ und besonders in Version 9.0 ist die Einrichtung deutlich einfacher geworden – besonders durch die Web-UI Device Passthrough Funktion.

Der große Vorteil gegenüber VM-Passthrough: Du bist nicht auf einen einzigen Dienst beschränkt und kannst die GPU-Ressourcen flexibel zwischen verschiedenen Anwendungen teilen. Mit der Unterstützung für unprivilegierte Container ist dies jetzt auch sicher möglich.

Weiterführende Ressourcen

Hast du Fragen oder eigene Erfahrungen mit GPU-Sharing in Proxmox? Teile sie gerne in den Kommentaren!

Intel iGPU Hardware-Transcodierung in Proxmox LXC Container einrichten

Detaillierte Anleitung zur Einrichtung von Intel GPU Hardware-Transcodierung in Proxmox LXC Containern mit Debian 13. Inklusive Konfiguration, Leistungstests und praktischen FFmpeg-Befehlen für 3-4x schnellere Video-Transcodierung.

In diesem Artikel zeige ich Ihnen, wie Sie Intel GPU Hardware-Transcodierung in einem Proxmox LXC Container erfolgreich einrichten. Diese Anleitung basiert auf einer getesteten Konfiguration mit Debian 13 (Trixie) und einer Intel Alder Lake-N Grafikkarte.

Systemvoraussetzungen

Für dieses Setup benötigen Sie:

  • Host-System: Proxmox VE 9.0 oder höher
  • Container OS: Debian 13 (Trixie) – empfohlen wegen aktueller Treiber
  • Intel GPU: Integrierte Intel Grafik (getestet mit Alder Lake-N)
  • Kernel: Proxmox Kernel 6.14.8-2-pve oder neuer

Die GPU muss bereits im Proxmox Container konfiguriert sein (Device Passthrough). In unserem Fall war die PCI-Adresse 0000:00:02.0.

Schritt 1: Grundlegende Pakete installieren

Melden Sie sich als root in Ihrem Container an und installieren Sie zunächst die grundlegenden Tools:

apt update
apt install -y pciutils udev

Überprüfen Sie, ob die GPU erkannt wird:

lspci | grep VGA
# Ausgabe sollte Ihre Intel GPU zeigen

Schritt 2: Intel Treiber und VA-API installieren

Installieren Sie alle notwendigen Intel-Treiber und VA-API Komponenten:

# Intel Media Treiber
apt install -y intel-media-va-driver-non-free i965-va-driver

# VA-API Bibliotheken und Tools
apt install -y libva2 libva-dev vainfo va-driver-all

# Intel spezifische Bibliotheken
apt install -y libigdgmm12 libvpl2 libmfx-gen1.2

# Monitoring Tools
apt install -y intel-gpu-tools

Schritt 3: FFmpeg mit Hardware-Unterstützung installieren

apt install -y ffmpeg

Debian Trixie liefert FFmpeg bereits mit vollständiger Intel QSV (Quick Sync Video) Unterstützung aus.

Schritt 4: Umgebungsvariablen konfigurieren

Erstellen Sie die Datei /etc/environment mit folgendem Inhalt:

LIBVA_DRIVER_NAME=iHD
LIBVA_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri

Diese Variablen stellen sicher, dass der Intel iHD Treiber verwendet wird.

Schritt 5: Installation überprüfen

VA-API Test

# VA-API Unterstützung prüfen
vainfo --display drm --device /dev/dri/renderD128

Sie sollten eine Liste der unterstützten Profile und Entrypoints sehen, einschließlich:

  • VAProfileH264Main
  • VAProfileHEVCMain
  • VAProfileVP9Profile0

FFmpeg QSV Support

# Verfügbare Hardware-Beschleuniger anzeigen
ffmpeg -hide_banner -hwaccels | grep qsv

# QSV Encoder auflisten
ffmpeg -hide_banner -encoders | grep qsv

Schritt 6: Test-Script erstellen

Erstellen Sie /root/test_gpu_transcoding.sh mit folgendem Inhalt:

#!/bin/bash

echo "=== Intel GPU Transcoding Test Script ==="
echo

# Farben für Ausgabe
GREEN='\033[0;32m'
RED='\033[0;31m'
NC='\033[0m' # No Color

# Test 1: VA-API Check
echo "1. Checking VA-API support..."
if vainfo --display drm --device /dev/dri/renderD128 2>/dev/null | grep -q "VAProfileH264Main"; then
    echo -e "${GREEN}✓ VA-API is working${NC}"
else
    echo -e "${RED}✗ VA-API not working${NC}"
    exit 1
fi
echo

# Test 2: FFmpeg QSV Check
echo "2. Checking ffmpeg QSV support..."
if ffmpeg -hide_banner -encoders 2>/dev/null | grep -q h264_qsv; then
    echo -e "${GREEN}✓ FFmpeg QSV support detected${NC}"
else
    echo -e "${RED}✗ FFmpeg QSV support not found${NC}"
    exit 1
fi
echo

# Test 3: Create test video
echo "3. Creating test video..."
ffmpeg -f lavfi -i testsrc=duration=5:size=1280x720:rate=30 \
       -f lavfi -i sine=frequency=1000:duration=5 \
       -c:v libx264 -preset ultrafast -c:a aac \
       -y /tmp/test_input.mp4 2>/dev/null
echo -e "${GREEN}✓ Test video created${NC}"
echo

# Test 4: Software encoding
echo "4. Testing software H.264 encoding..."
START=$(date +%s%N)
ffmpeg -i /tmp/test_input.mp4 -c:v libx264 -preset faster \
       -b:v 2M -c:a copy -y /tmp/test_sw.mp4 2>/dev/null
END=$(date +%s%N)
SW_TIME=$((($END - $START)/1000000))
echo -e "${GREEN}✓ Software encoding: ${SW_TIME}ms${NC}"
echo

# Test 5: Hardware encoding
echo "5. Testing hardware H.264 QSV encoding..."
export LIBVA_DRIVER_NAME=iHD
START=$(date +%s%N)
ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 \
       -i /tmp/test_input.mp4 -c:v h264_qsv -preset faster \
       -b:v 2M -c:a copy -y /tmp/test_hw.mp4 2>/dev/null
END=$(date +%s%N)
HW_TIME=$((($END - $START)/1000000))
echo -e "${GREEN}✓ Hardware encoding: ${HW_TIME}ms${NC}"
echo

# Performance comparison
SPEEDUP=$(echo "scale=1; $SW_TIME / $HW_TIME" | bc)
echo "=== Performance Summary ==="
echo "Software encoding: ${SW_TIME}ms"
echo "Hardware encoding: ${HW_TIME}ms"
echo -e "${GREEN}Hardware acceleration is ${SPEEDUP}x faster!${NC}"
echo

# Cleanup
rm -f /tmp/test_*.mp4

echo "All tests completed successfully!"

Machen Sie das Script ausführbar:

chmod +x /root/test_gpu_transcoding.sh

Leistungsvergleich

In unseren Tests mit einem 5-Sekunden 720p Video zeigten sich folgende Ergebnisse:

Encoding-MethodeZeitGeschwindigkeit
Software H.2641471msBaseline
Hardware H.264 (QSV)405ms3.6x schneller
Hardware HEVC (QSV)502ms2.9x schneller

Die Hardware-Beschleunigung erreichte dabei eine Transcodierungsgeschwindigkeit von:

  • 17x Echtzeit für H.264
  • 13x Echtzeit für HEVC

Unterstützte Codecs

Mit diesem Setup stehen folgende Hardware-Codecs zur Verfügung:

  • ✅ H.264/AVC (h264_qsv) – Encoding & Decoding
  • ✅ HEVC/H.265 (hevc_qsv) – Encoding & Decoding
  • ✅ VP9 (vp9_qsv) – Encoding & Decoding
  • ✅ MPEG-2 (mpeg2_qsv) – Encoding & Decoding
  • ✅ MJPEG (mjpeg_qsv) – Encoding
  • ⚠️ AV1 (av1_qsv) – Je nach GPU-Generation

Praktische FFmpeg Befehle

H.264 Transcodierung mit QSV

export LIBVA_DRIVER_NAME=iHD
ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -i input.mp4 \
    -c:v h264_qsv -preset faster -b:v 2M -c:a copy output.mp4

HEVC/H.265 Transcodierung

ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -i input.mp4 \
    -c:v hevc_qsv -preset faster -b:v 1M -c:a copy output_hevc.mp4

Vollständige Hardware-Pipeline (Decode + Encode)

ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 \
    -c:v hevc_qsv -preset faster -b:v 1M -c:a copy output.mp4

GPU-Auslastung überwachen

⚠️ Wichtiger Hinweis: Das Tool intel_gpu_top erfordert einen privilegierten Container für vollen Zugriff auf GPU-Metriken. Falls der Befehl mit einem Fehler wie „Failed to detect engines“ fehlschlägt, müssen Sie Ihren Container als privilegiert konfigurieren:

In der Proxmox Container-Konfiguration unter Options → Features aktivieren Sie:

  • Nesting (für Container-in-Container)
  • Fügen Sie in der Container-Konfigurationsdatei /etc/pve/lxc/[CTID].conf folgende Zeile hinzu:
    lxc.apparmor.profile: unconfined

Mit intel_gpu_top können Sie die GPU-Auslastung in Echtzeit beobachten:

intel_gpu_top

Dies zeigt Ihnen die Auslastung der verschiedenen GPU-Engines, einschließlich der Video-Engine während der Transcodierung.

Alternativ können Sie auch grundlegende GPU-Informationen ohne privilegierten Zugriff abrufen:

# GPU-Frequenz anzeigen
cat /sys/class/drm/card*/gt_cur_freq_mhz

# GPU-Speichernutzung
cat /sys/kernel/debug/dri/*/i915_gem_objects

Anwendungsfälle

Dieses Setup eignet sich hervorragend für:

  • Video-Streaming-Dienste: Jellyfin, Plex, Emby mit Hardware-Transcodierung
  • Live-Streaming: OBS Studio mit QSV Encoder
  • Videokonvertierung: Batch-Konvertierung großer Videobibliotheken
  • Überwachungskameras: Motion Detection und Aufzeichnung mit geringer CPU-Last
  • Videokonferenz-Server: Jitsi, BigBlueButton mit Hardware-Beschleunigung

Fehlerbehebung

Problem: VA-API funktioniert nicht

Prüfen Sie die Berechtigungen der DRM-Geräte:

ls -la /dev/dri/
# renderD128 sollte lesbar sein

Problem: FFmpeg findet QSV nicht

Stellen Sie sicher, dass die Umgebungsvariable gesetzt ist:

export LIBVA_DRIVER_NAME=iHD

Problem: Schlechte Performance

Überprüfen Sie mit intel_gpu_top, ob die GPU tatsächlich verwendet wird. Die Video-Engine sollte während der Transcodierung aktiv sein.

Fazit

Die Einrichtung der Intel GPU Hardware-Transcodierung in einem Proxmox LXC Container bietet erhebliche Leistungsvorteile. Mit einer 3-4fachen Geschwindigkeitssteigerung gegenüber Software-Encoding und Unterstützung für moderne Codecs ist das System ideal für medienintensive Anwendungen.

Die Kombination aus Debian Trixie’s aktuellen Treibern und Proxmox’s Container-Technologie ermöglicht eine effiziente und isolierte Umgebung für Video-Transcodierung mit minimaler CPU-Belastung.

Haben Sie Fragen oder Erfahrungen mit diesem Setup? Hinterlassen Sie gerne einen Kommentar!

KI am Arbeitsplatz: Das neue Office – Warum wir alle lernen müssen, mit künstlicher Intelligenz zu arbeiten

Neulich hatte ich ein Gespräch mit einem Kollegen, das mich zum Nachdenken gebracht hat. Er saß vor seinem Laptop, bastelte an irgendwelchen Diagrammen und Planungen herum. Als ich ihm sagte, dass sowas zukünftig auch die KI für ihn machen könnte, kam eine Antwort, die mich aufhorchen ließ: „Das KI-Zeug habe ich dreimal ausprobiert, dreimal eine bescheidene Antwort bekommen – brauche ich nicht.“

Die Realität außerhalb der Tech-Bubble

Mein Kollege ist ein bodenständiger Familienvater, kein Technik-Nerd, sondern jemand mit einem echten Leben außerhalb der digitalen Welt. Und genau solche Menschen gibt es millionenfach. Das muss man respektieren – nicht jeder lebt in einer Technik-Bubble, wo KI allgegenwärtig ist.

Aber hier liegt das Problem: Während mein YouTube-Feed von oben bis unten mit KI-Content gefüllt ist, beschäftigt sich die arbeitende Bevölkerung mehrheitlich noch nicht ernsthaft mit diesem Thema. Viele sehen keinen Grund, sich in ihrer Freizeit damit auseinanderzusetzen oder den Chef zu drängen, entsprechende Schulungen anzubieten.

KI wird das neue Office

Dabei ist KI nichts anderes als das, was damals mit Office-Programmen passiert ist. Outlook, Excel, Word, PowerPoint – das mussten wir alle irgendwann lernen. Auch die Computer-Verweigerer, die sagten: „Ich brauche das nicht, ich habe meinen Ordner, meinen Stift und meinen Kopierer.“

Heute kann jeder Basic-Office-Programme bedienen, sonst ist man beruflich raus. Bei KI wird es genauso laufen. Wer heute nicht lernt, mit diesen Tools umzugehen, wird morgen ersetzt – nicht durch die KI selbst, sondern durch den Kollegen, der es gelernt hat.

Der falsche Mythos vom KI-Ersatz

Viele Chefs und Investoren glauben fälschlicherweise, sie könnten Informationsmitarbeiter einfach durch KI ersetzen. Das ist grundfalsch. Klar, sie werden es zunächst versuchen: „Warum einen Mitarbeiter für Social Media Postings bezahlen, wenn mein Copilot das auch kann?“

Aber ein ein- oder zweizeiliger Social Media Post ist etwas völlig anderes als ein Businessplan, eine wissenschaftliche Arbeit oder komplexe Programmierung. Für alles Größere braucht die KI das Fachwissen eines Menschen, der sie anleiten kann.

KI als Produktivitäts-Booster

Der Trick liegt darin, KI mit Kontext zu füttern: mit Informationen, Dokumentation, projektspezifischen Daten. Du arbeitest quasi gemeinsam mit der KI einen Plan aus – wie ein Dompteur einer Engineering-Abteilung.

Die KI erhöht den Output eines Mitarbeiters, der weiß, was er tut und wie er das der KI beibringt. Den Mitarbeiter kann man nicht einfach ersetzen. Aber sehr wohl kann man jemanden ersetzen, der sagt: „Brauche ich nicht“ – denn dessen Job macht dann der Kollege, der sich mit KI beschäftigt hat und plötzlich den zehnfachen Output produziert.

Das Skillset der Zukunft

Was wird zukünftig wichtig sein? Eine Sammlung von „Voreinstellungsdateien“ – Prompts und Anweisungen, mit denen du KI-Systeme für verschiedene Aufgaben konfigurierst. Das ist wie das initiale Priming: „Lege immer ein Git-Repository an, achte auf Versionskontrolle, verwende diese Dateistruktur.“

Dazu kommen projektspezifische Vorgaben. Ob du ein Buch schreibst oder Ausschreibungen erstellst – du baust dir Templates und fütterst sie mit projektspezifischen Daten. Dann gibst du der KI Input für zehn Projekte und sie macht die Arbeit von zehn Leuten gleichzeitig.

Künstliche Idioten, nicht künstliche Intelligenz

Der Begriff „künstliche Intelligenz“ ist Marketing-Blabla. Es sind eher „künstliche Idioten“ – wie Savants, die etwas furchtbar gut können (ganz viel, ganz schnell), aber trotzdem angeleitet werden müssen. Sie können das Telefonbuch auswendig lernen, aber danach niemanden anrufen.

Wir müssen diesen Systemen beibringen, wie die Welt funktioniert. Das kostet Zeit und Lernaufwand, aber es ist unvermeidlich.

KI für den Menschen, nicht für den Investor

Die Zukunft heißt KI für den Menschen, nicht für Investoren oder Chefs, die auf dem Hype-Train sitzen. Es geht darum, der Allgemeinheit zugänglich zu machen, warum dieses Thema wichtig ist.

Die Wahrheit ist: Du wirst nicht durch KI ersetzt, sondern durch deinen Kollegen, der gelernt hat, mit KI zu arbeiten und dadurch den zehnfachen Output produziert. Die Competition ist nicht mit der KI, sondern mit dem Arbeitskollegen nebenan.

Es ist wie früher: persönliche Weiterentwicklung, Wissen aneignen, neue Werkzeuge beherrschen. Wer das versteht und umsetzt, bleibt relevant. Wer es ignoriert, wird abgehängt.

Fazit

KI ist kein Hype, sondern das nächste Office. Jeder, der beruflich überleben will, muss lernen, brauchbare und wiederholbare Ergebnisse aus diesen Systemen herauszuholen. Die Zeit der Ausreden ist vorbei – entweder du lernst es, oder dein Kollege übernimmt deinen Job mit zehnfacher Produktivität.

Beschäftige dich damit. Es ist wichtiger, als du denkst.

Bestseller Nr. 1
Claude Code: The Unofficial Guide (English Edition)
Claude Code: The Unofficial Guide (English Edition)
  • Harmon, James(Autor)
4,28 EUR
Bei Amazon kaufen
Bestseller Nr. 2
Claude Code in Action: Mastering Git Workflows, Multi-File Edits, CI/CD, and Agentic Reasoning with Claude Sonnet & Opus
Claude Code in Action: Mastering Git Workflows, Multi-File Edits, CI/CD, and Agentic Reasoning with Claude Sonnet & Opus
  • McCleary, Adam(Autor)
16,45 EUR Amazon Prime
Bei Amazon kaufen
Bestseller Nr. 3
Mastering Claude Code from Scratch: Prompt Engineering, RAG, Workflow Automation and AI Agents (English Edition)
Mastering Claude Code from Scratch: Prompt Engineering, RAG, Workflow Automation and AI Agents (English Edition)
  • Ossie, Robert (Autor)
6,80 EUR
Bei Amazon kaufen

OPNsense VM Platte voll?

Auf einer meiner OPNsense VMs war die zugewiesene Platte voll. Das lässt sich ganz einfach beheben, wie in folgendem Video beschrieben:

Hier habe ich dir noch schnell die passenden Befehle rausgeschrieben.

Zum Anzeigen der Plattenbelegung:

gpart show

Nach dem Vergrößern der Platte musst du zuerst die Partitionstabelle fixen:

gpart recover da0

Setze dabei für da0 die Bezeichnung deiner Patte ein.

Jetzt kannst du die Partition vergrößern:

gpart resize -i 4 da0

Passe dabei auf, die richtige Partitionsnummer einzusetzen.

Überprüfe die erfolgreiche Vergrößerung:

gpart show

Jetzt musst du noch das root-Filesystem vergrößern, dazu musst du unterscheiden, ob du ein UFS oder ZFS hast.

Für UFS:

growfs /dev/gpt/rootfs

Und für ZFS:

zpool online -e zroot da0p4

Hierbei auch wieder aufpassen wegen der Platte und Partition. da0p4 in meinem Fall heißt einfach Platte da0 und Partition 4

Das war’s auch schon 🙂

Falls du noch passende Hardware suchst um deine OPNsense aus der Virtualisierung zu befreien, dann schau doch mal meine Amazon-Links an. Falls etwas für dich dabei ist, würde ich mich freuen wenn du es über meinen Link bestellst, dir entstehen dabei keinerlei Mehrkosten und ich erhalte einen kleinen Anteil von Amazon.

Keine Produkte gefunden.

Synology Let’s Encrypt DNS-Challenge mit IPv64

SSL-Zertifikate?

Secure Socket Layer (SSL)-Zertifikate sind das, was dein Browser verwendet, um eine Website sicher zu kontaktieren und Benutzernamen, Passwörter, Kreditkartendaten usw. zu schützen. Auf den Synology-Geräten ist standardmäßig ein „self-signed“ Zertifikat installiert. Diese bieten zwar Sicherheit, aber der Webbrowser beschwert sich darüber und man muss verschiedene Schaltflächen/Links anklicken, um zur Website zu gelangen. Fragt man nahezu jeden Enterprise-Administrator nach dieser Unannehmlichkeit, sind selbstsignierte SSL-Zertifikate ein alter Hut – sie finden sich in zahlreichen Administrations-Tools. Für einen Endnutzer wirkt es jedoch nicht sonderlich vertrauenserweckend, wenn er Fehlermeldungen wegklicken muss, um auf ein System zuzugreifen, das wichtige und potenziell sensible Daten enthält.

Angebot
Synology DS223 2-Bay Diskstation NAS (Realtek RTD1619B Quad-Core 2GB Ram 1xRJ-45 1GbE LAN-Port), Schwarz
Synology DS223 2-Bay Diskstation NAS (Realtek RTD1619B Quad-Core 2GB Ram 1xRJ-45 1GbE LAN-Port), Schwarz
  • Hochwertige Material
  • Langlebig
  • Robustheit
  • Flexible Gestaltung
266,00 EUR Amazon Prime
Bei Amazon kaufen
Angebot
Synology DiskStation DS224+ 2 Bay Dekstop NAS
Synology DiskStation DS224+ 2 Bay Dekstop NAS
  • Centralized Data Storage – Consolidate all your data for complete data ownership and multi-platform access
  • Sharing and Syncing Across Systems – Access, share, and sync data across different systems and devices using intuitive controls
  • Powerful Backup and Restoration – Back up and restore critical devices and data using a host of intuitive backup tools
  • Built-in Data Management Tools – Leverage built-in file and photo management, data protection, and video surveillance solutions
335,90 EUR Amazon Prime
Bei Amazon kaufen

Es GIBT zwar eine eingebaute Methode, ein gültiges SSL-Zertifikat auf einem Synology-Gerät zu bekommen, doch sie hat einen entscheidenden Nachteil: Dein Synology-Gerät muss dafür auf den Ports 80 und 443 über das öffentliche Internet erreichbar sein ODER du musst den Synology-DDNS-Service nutzen. Für manche Nutzer ist das vielleicht kein großes Problem, aber ich glaube nicht, dass die Mehrheit ihr Synology-Gerät öffentlich zugänglich machen oder eine merkwürdige URL (z. B. DeviceName.synology.me) verwenden möchte, um auf die Daten zuzugreifen.

Die Lösung?

Let’s Encrypt stellt kostenlose SSL-Zertifikate zur Verfügung, und acmesh (https://github.com/acmesh-official/acme.sh) bietet ein Skript, das genutzt werden kann, ohne dass Port 80 und 443 für das öffentliche Internet offen sind.

Wo ist der Haken?

Nun ja, ein bisschen gibt es da schon. Du brauchst eine Domain bei einem Registrar, der eine Programmierschnittstelle (API) bereitstellt, um bestimmte Einträge zu aktualisieren. acme.sh unterstützt auch https://IPv64.net – yay! Andere Anbieter sollten ebenfalls problemlos funktionieren, und das meiste in diesem Beitrag sollte auch für sie passen. Getestet habe ich allerdings nur mit IPv64. Deine Ergebnisse können variieren („YMMV“).

Wo fängt man an?

Als Erstes: Stell sicher, dass du einen Domainnamen bei deinem bevorzugten Registrar oder DynDNS-Anbieter (IPv64 in meinem Fall) registriert hast und beschaffe dir den API-Key. Bei IPv64 kannst du dir den API-Key in deiner Domainübersicht (für die Domain zu der das Zertifikat dann erstellt werden soll) besorgen, er steht auf der rechten Seite und kann dort kopiert werden. Sobald du den API-Key hast, kann es losgehen!

Erstelle einen Benutzer in Synology DSM

Melde dich bei deinem Synology-Gerät an, klicke auf „Systemsteuerung“ und dann auf „Benutzer und Gruppe“. Klicke auf „Erstellen“. Ich habe den Benutzernamen „certadmin“ gewählt und eine entsprechende Beschreibung hinzugefügt. Der Benutzer muss Mitglied der Gruppe „administrators“ sein (das ist erforderlich für den SSH-Zugriff, den wir gleich nutzen werden) und außerdem in der Gruppe „http“ (das ist nötig, damit sich der Prozess im SSH-Session-Kontext bei DSM authentifizieren kann). Der Benutzer „certadmin“ benötigt nur Lese-/Schreibzugriff auf den Ordner „homes“ und du kannst den Zugriff auf alle Anwendungen verweigern. Wenn du den Benutzer erstellt hast, gehe zurück zur „Systemsteuerung“, klicke auf „Terminal & SNMP“ und setze ein Häkchen bei „SSH-Dienst aktivieren“. Klicke auf „Übernehmen“.

Jetzt wird’s spannend!

Wahrscheinlich bist du hier, um eine Anleitung zu bekommen und nicht, um meine ganzen Erklärungen zu lesen – also los!

Verwende einen SSH-Client (z. B. https://www.putty.org für Windows; unter Linux ist SSH standardmäßig verfügbar). Wenn du Putty nutzt, gib dort die IP-Adresse oder den Hostnamen deines Synology-Geräts ein, wähle SSH und klicke auf „Open“. Es erscheint eine Sicherheitswarnung, die du mit „Yes“ bestätigen kannst. Anschließend wirst du nach dem Benutzernamen gefragt („certadmin“ in meinem Fall). Unter macOS oder Linux öffnest du ein Terminal und gibst Folgendes ein:

ssh certadmin@DEINHOSTODERIPADRESSE

Wenn du die Sicherheitswarnung bestätigst, wirst du nach deinem Passwort gefragt. Gib das Passwort ein, das du oben für den Synology-Benutzer festgelegt hast (bei der Eingabe erscheint möglicherweise kein Text) und drücke Enter. Lass dich nicht von der SSH-Sitzung abschrecken – die Kommandozeile ist dein Freund!

Die folgenden Befehle (kopiere sie nacheinander, wenn du möchtest) laden das Skript herunter, entpacken die ZIP-Datei, verschieben die Dateien in einen anderen Ordner, übertragen den Besitz der Dateien an den neuen Benutzer und wechseln in das richtige Verzeichnis. Jeder dieser Befehle sollte in einer einzelnen Zeile ausgeführt werden. Die meisten Befehle stammen aus https://www.driscocity.com/synology-dsm-6-2-lets-encrypt-dns-challenge-route53/.

wget -O /tmp/acme.sh.zip https://github.com/acmesh-official/acme.sh/archive/master.zip
(==> da ist kein Zeilenumbruch, die Zeile wurde nur zu lang)

sudo 7z x -o/usr/local/share /tmp/acme.sh.zip

sudo mv /usr/local/share/acme.sh-master/ /usr/local/share/acme.sh

sudo chown -R certadmin /usr/local/share/acme.sh/

cd /usr/local/share/acme.sh

Nun haben wir die notwendigen Dateien. Jetzt müssen wir ein paar Variablen anlegen, damit das Skript funktioniert. Ersetze die Platzhalter unbedingt durch deine eigenen Informationen!

export IPv64_Token="DEIN_GODADDY_KEY"
export SYNO_Username="certadmin"
export SYNO_Password="DEIN_CERTADMIN_PASSWORT"
export SYNO_Certificate="Let's Encrypt"
export SYNO_Create=1

Wenn du nicht IPv64 als Domain-Registrar/DynDNS-Provider verwendest, kannst du unter
https://github.com/acmesh-official/acme.sh/wiki/dnsapi nach den entsprechenden export-Befehlen für andere Registrare schauen.

Verwende zum Erstellen des ersten Zertifikats folgenden Befehl. Achte darauf, deinen Domainnamen zu ersetzen!

./acme.sh --server letsencrypt --issue -d "*.DEINEDOMAIN.NAME" --dns dns_ipv64 --home $PWD
(==> auch hier: kein Zeilenumbruch!)

Wenn du einen anderen Registrar verwendest, musst du in der oben genannten Github-Dokumentation nachlesen, welchen Wert du für --dns benötigst.

Der Vorgang dauert ca. eine Minute. Keine Sorge: Auf dem Bildschirm siehst du Ausgaben, die den Fortschritt zeigen. Dieser Prozess erstellt und lädt das Zertifikat zwar auf dein Synology-Gerät, sagt diesem aber noch nicht, dass es verwendet werden soll. Das erledigt folgender Befehl:

./acme.sh -d "*.DEINEDOMAIN.NAME" --deploy --deploy-hook synology_dsm --home $PWD
(==> auch hier: kein Zeilenumbruch!)

Du solltest einige Meldungen sehen, die anzeigen, dass sich das Skript erfolgreich bei deinem Synology-Gerät anmelden konnte, die Zertifikate abruft, sie anwendet und den Webserver neu startet.

Das automatische zuweisen der Zertifikate und der Neustart des HTTP-Servers hat bei mir nicht geklappt, ich musste die Zertifikate manuell im DSM zuordnen. Dazu klickst du in der Systemsteuerung auf „Sicherheit“ und dann „Zertifikat“. Dann klickst du auf die Schaltfläche Einstellungen und ordnest dein neues Zertifikat für alle Dienste zu. Beim klicken auf ok werden die Dienste neu gestartet und das neue Zertifikat ist aktiv.

Wenn du dich jetzt per HTTPS bei deinem Synology anmeldest, solltest du ein gültiges Zertifikat sehen!

Wenn du ein gültiges und funktionierendes SSL-Zertifikat hast, stelle sicher, dass deine Browser es verwenden! Melde dich bei deinem Synology-Gerät an, gehe in die Systemsteuerung und rufe „Anmeldeportal“ auf. Setze ein Häkchen bei „HTTP-Verbindungen automatisch zu HTTPS umleiten“ und klicke auf „Speichern“. Sobald alles nach Wunsch funktioniert, gehe wieder zur Systemsteuerung und deaktiviere unter „Terminal & SNMP“ den SSH-Zugriff. Denk dran: Das Deaktivieren unnötiger Dienste ist ein guter Sicherheitsgrundsatz!

Und was kommt jetzt?

Das Zertifikat ist installiert und funktioniert. Wenn du allerdings prüfst, wirst du feststellen, dass es nur 90 Tage gültig ist. Du kannst es ganz einfach automatisch verlängern, indem du in deinem Synology-Gerät in die Systemsteuerung gehst, den „Aufgabenplaner“ öffnest, auf „Erstellen“ und „Geplante Aufgabe“ klickst und „Benutzerdefiniertes Skript“ auswählst. Gib der Aufgabe einen aussagekräftigen Namen und achte darauf, dass als Benutzer „certadmin“ ausgewählt ist. Plane die Aufgabe so, dass sie täglich ausgeführt wird, und trage im Reiter „Aufgabeneinstellungen“ das benutzerdefinierte Skript ein. In meinem Fall sieht das so aus:

/usr/local/share/acme.sh/acme.sh --renew -d "*.DEINEDOMAIN.NAME" --home /usr/local/share/acme.sh --server letsencrypt
(==> auch hier: kein Zeilenumbruch!)

Das war’s!

Nur ein paar relativ einfache Schritte, und du hast ein gültiges SSL-Zertifikat auf deinem Synology-Gerät, das sich automatisch verlängert, bevor es abläuft.

Quellenangabe

Anleitung gefunden auf:
https://dr-b.io/post/Synology-DSM-7-with-Lets-Encrypt-and-DNS-Challenge

Angepasst für IPv64 und ein wenig bereinigt.