TrueNAS SCALE Virtualisierung: Docker, LXC und KVM richtig einsetzen

TrueNAS SCALE vereint Storage und Compute auf einer Plattform. Neben der eigentlichen Aufgabe als Network Attached Storage bietet SCALE drei Virtualisierungstechnologien: Docker-Container über die Apps-Infrastruktur, LXC-Container als leichtgewichtige Linux-Umgebungen und KVM-basierte VMs für vollständig isolierte Betriebssysteme. Doch wann ist welche Methode die richtige Wahl?

Überblick: Drei Technologien im Vergleich

Merkmal	Docker (Apps)	LXC-Container	KVM-VM
Isolation	Namespace-basiert	Namespace + cgroups	Vollständige Hardware-Virtualisierung
Kernel	Host-Kernel	Host-Kernel	Eigener Kernel
Overhead	Minimal	Gering	Moderat
Startzeit	Sekunden	Sekunden	30–60 Sekunden
Betriebssysteme	Linux-basiert	Linux	Linux, Windows, BSD
GPU Passthrough	Begrenzt	Nein	Ja (IOMMU)
Einsatzbereich	Microservices, Apps	Systemdienste	Volle OS-Instanzen

Docker-Container auf TrueNAS SCALE

TrueNAS SCALE nutzt seit Dragonfish (24.04) Docker als native Container-Runtime. Die bisherige Kubernetes-Infrastruktur wurde durch ein schlankeres Docker-Compose-Backend ersetzt. Container werden über die Web-GUI als Apps bereitgestellt.

App-Kataloge und Custom Apps

Der offizielle TrueNAS-App-Katalog bietet über 100 vorkonfigurierte Anwendungen. Für eigene Images steht die Custom App zur Verfügung:

# Beispiel: Custom App als Docker Compose
services:
  nginx-proxy:
    image: nginx:alpine
    ports:
      - "8080:80"
    volumes:
      - /mnt/data/nginx/html:/usr/share/nginx/html:ro
      - /mnt/data/nginx/conf:/etc/nginx/conf.d:ro
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 512M

Resource Limits konfigurieren

Container ohne Ressourcen-Limits können den Host destabilisieren. In TrueNAS SCALE lassen sich Limits direkt in der App-Konfiguration setzen:

• CPU-Limit: Maximale Anzahl an CPU-Kernen (z. B. 2.0 für zwei Kerne)
• Memory-Limit: Maximaler RAM-Verbrauch (z. B. 512M oder 2G)
• CPU-Shares: Relative Gewichtung bei CPU-Kontention

# Laufende Container-Limits prüfen
docker stats --no-stream

Netzwerk-Konfiguration

Docker-Container in TrueNAS SCALE nutzen standardmäßig ein Bridge-Netzwerk. Für direkte Netzwerkanbindung kann macvlan oder host networking konfiguriert werden:

services:
  pihole:
    image: pihole/pihole:latest
    networks:
      lan:
        ipv4_address: 192.168.1.50
    environment:
      TZ: "Europe/Berlin"

networks:
  lan:
    driver: macvlan
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1

Macvlan gibt dem Container eine eigene IP-Adresse im physischen Netzwerk — ideal für Dienste wie Pi-hole oder Home Assistant, die im LAN erreichbar sein müssen.

LXC-Container auf TrueNAS SCALE

Mit TrueNAS SCALE Electric Eel (24.10) wurden LXC-Container als Alternative zu Docker eingeführt. LXC bietet vollständige Linux-Umgebungen mit eigenem Init-System, Paketmanager und Benutzer-Management.

Wann LXC statt Docker?

LXC-Container eignen sich besonders für:

• Systemdienste, die ein vollständiges Linux-System erwarten (Samba, NFS-Server)
• Multi-Prozess-Workloads, die einen init-Prozess benötigen
• Entwicklungsumgebungen, die eine vollständige Distribution abbilden
• Legacy-Anwendungen, die nicht containerisiert wurden

LXC-Container erstellen

In der TrueNAS-Web-GUI unter Virtualization > Containers:

1. Image auswählen: Ubuntu 24.04, Debian 12, Alpine Linux etc.
2. Ressourcen zuweisen: CPU-Cores, RAM, Disk-Quota
3. Netzwerk konfigurieren: Bridge oder direkte NIC-Zuweisung
4. Storage Mounts: ZFS-Datasets als Bind-Mounts einbinden

# LXC-Container über die CLI verwalten
incus list
incus exec my-container -- bash
incus config set my-container limits.cpu 4
incus config set my-container limits.memory 4GiB

Sicherheit: Unprivilegierte Container

TrueNAS SCALE erstellt LXC-Container standardmäßig als unprivilegierte Container. Das bedeutet: Der Root-User im Container wird auf einen nicht-privilegierten UID-Bereich auf dem Host gemappt.

# UID-Mapping prüfen
incus config show my-container | grep -A5 raw.idmap

Unprivilegierte Container bieten einen wichtigen Sicherheitsvorteil: Selbst wenn ein Angreifer Root im Container erlangt, hat er auf dem Host keinerlei Rechte.

KVM-VMs: Vollständige Virtualisierung

KVM-VMs bieten die höchste Isolation und Flexibilität. Sie eignen sich für:

• Windows-Server und andere Nicht-Linux-Betriebssysteme
• Workloads mit GPU-Anforderungen (Passthrough via IOMMU)
• Sicherheitskritische Anwendungen mit maximaler Isolation
• Cluster-Knoten (z. B. Proxmox VE als Nested Hypervisor)

VM erstellen und konfigurieren

Unter Virtualization > Virtual Machines in der TrueNAS-Web-GUI:

Name:          win-server-2025
CPU:           4 Threads (Typ: host)
RAM:           8192 MB
Disk:          zvol auf data-pool (64 GB, virtio-blk)
NIC:           virtio, Bridge br0
Boot:          UEFI (OVMF)
VNC:           Aktiviert (Port 5900)

Wichtig: Den CPU-Typ auf host setzen, um die nativen CPU-Features an die VM durchzureichen. Das verbessert die Performance erheblich gegenüber dem Standard-Typ qemu64.

GPU Passthrough einrichten

Für GPU-beschleunigte Workloads (Plex Transcoding, KI-Inferenz, CAD) kann eine dedizierte GPU per IOMMU an eine VM durchgereicht werden:

# 1. IOMMU im BIOS aktivieren (Intel VT-d / AMD-Vi)

# 2. IOMMU in der Boot-Konfiguration aktivieren
# In /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on iommu=pt"

# 3. IOMMU-Gruppen prüfen
for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*}; n=${n%%/*}
  printf 'IOMMU Group %s: ' "$n"
  lspci -nns "${d##*/}"
done

# 4. GPU-Treiber auf dem Host blockieren (vfio-pci nutzen)
echo "options vfio-pci ids=10de:2484,10de:228b" > /etc/modprobe.d/vfio.conf

In der TrueNAS-GUI die GPU anschließend unter GPU Devices der VM zuweisen. Die VM erhält exklusiven Zugriff auf die GPU.

VirtIO-Treiber für Windows

Windows-VMs benötigen VirtIO-Treiber für optimale Performance:

1. VirtIO-ISO herunterladen von fedorapeople.org
2. Als zweites CD-ROM in die VM einbinden
3. Während der Windows-Installation die Treiber laden
4. Nach der Installation den QEMU Guest Agent installieren

# VirtIO Guest Agent Service prüfen (PowerShell in der Windows-VM)
Get-Service QEMU-GA | Select-Object Status, StartType

Sandboxing und Sicherheit

Docker-Sicherheit

services:
  app:
    image: myapp:latest
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

Grundregeln für Docker auf TrueNAS:

• no-new-privileges: Verhindert Privilege Escalation
• read_only: Dateisystem nur lesbar (tmpfs für temporäre Daten)
• cap_drop: ALL: Alle Linux Capabilities entfernen, nur benötigte hinzufügen
• Kein privileged: true: Niemals, es sei denn absolut unvermeidbar

Netzwerk-Isolation

Für sicherheitskritische Container empfiehlt sich eine Netzwerk-Segmentierung:

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # Kein Internetzugang

services:
  web:
    networks: [frontend, backend]
  database:
    networks: [backend]  # Nur intern erreichbar

Best Practices für TrueNAS-Virtualisierung

Ressourcen-Planung

Eine bewährte Faustregel für die Ressourcenverteilung:

• TrueNAS-System: Mindestens 2 CPU-Kerne und 8 GB RAM reservieren
• ZFS ARC: Mindestens 1 GB RAM pro TB Speicher einplanen
• VMs/Container: Restliche Ressourcen zuweisen, nie überbuchen

# Aktuelle Ressourcennutzung prüfen
free -h
arc_summary | head -30
docker stats --no-stream

Storage-Anbindung

Für Container und VMs empfehlen sich dedizierte ZFS-Datasets:

# Dataset-Struktur für Container-Daten
zfs create data-pool/apps
zfs create data-pool/apps/nginx
zfs create data-pool/apps/postgres
zfs create data-pool/vms

# Separate Recordsize für VM-Zvols
zfs set volblocksize=64K data-pool/vms

Datasets statt eines einzelnen Verzeichnisses bieten unabhängige Snapshots, Quotas und Komprimierungseinstellungen pro Anwendung.

Backup-Strategie

Unabhängig von der Virtualisierungsmethode:

• Docker-Apps: Volumes und Compose-Files per ZFS-Snapshot sichern
• LXC-Container: Incus-Export oder ZFS-Snapshot des Container-Datasets
• KVM-VMs: ZFS-Snapshot des Zvols, QEMU Guest Agent für konsistente Snapshots

# Snapshot aller App-Daten
zfs snapshot -r data-pool/apps@backup-$(date +%Y%m%d)

# VM-Snapshot mit Freeze/Thaw (konsistent)
virsh domfsfreeze win-server-2025
zfs snapshot data-pool/vms/win-server-2025@backup-$(date +%Y%m%d)
virsh domfsthaw win-server-2025

Fazit

TrueNAS SCALE ist mehr als ein NAS — es ist eine vielseitige Plattform für Storage und Compute. Docker eignet sich für Microservices und vorkonfigurierte Apps, LXC für vollständige Linux-Umgebungen mit geringem Overhead, und KVM-VMs für maximale Isolation und Nicht-Linux-Systeme. Mit durchdachter Ressourcenplanung und Sicherheitskonfiguration lässt sich ein leistungsfähiges Heimlabor oder ein produktiver Unternehmensserver aufbauen, der Storage und Virtualisierung auf einer einzigen Maschine vereint.