iSCSI vs. NFS für Hypervisor-Storage: Wann was?

Wer einen TrueNAS-Pool als Storage für einen Hypervisor (VMware ESXi, Proxmox VE, Linux KVM, Microsoft Hyper-V) anbinden will, steht früh vor der Frage: iSCSI oder NFS? Beides funktioniert, beides ist seit Jahren produktiv im Einsatz, aber die Architektur unterscheidet sich grundlegend — und damit auch die Eignung für bestimmte Workloads.

Dieser Artikel ist eine pragmatische Entscheidungshilfe. Wir behandeln iSCSI (Block-Storage) und NFS (File-Storage), zeigen die Stärken und Schwächen und geben Empfehlungen für die gängigen Hypervisor-Plattformen.

Die Architektur in einem Satz

• iSCSI: Der Hypervisor sieht eine Block-Device-LUN (eine virtuelle Festplatte), die er wie eine lokale Disk behandelt. Das Dateisystem (VMFS bei VMware, LVM oder ext4 bei Linux) sitzt auf dem Hypervisor.
• NFS: Der Hypervisor mountet eine File-Freigabe vom Storage. Die VM-Disks sind einzelne Dateien (.vmdk, .qcow2, .raw) im NFS-Verzeichnis.

Das klingt klein — die Konsequenzen sind groß.

iSCSI im Detail

Vorteile

Performance bei kleinen Block-I/Os. Block-Storage hat keinen File-Locking-Overhead, kein Path-Resolving in einem File-System auf dem Storage-Pfad. Bei vielen kleinen I/Os (Datenbanken, VDI mit vielen Boot-VMs gleichzeitig) ist iSCSI traditionell schneller als NFS.

Multipathing nativ. iSCSI unterstützt MPIO (Multi-Path I/O) — mehrere Netzwerk-Pfade zum gleichen Storage, mit Failover und Load-Balancing. Das ist sowohl bei VMware (PSP-Policies wie Round Robin) als auch bei Linux (multipathd) etabliert. Siehe TrueNAS iSCSI Multipath für VMware.

VMFS-Cluster-Filesystem. VMware ESXi nutzt auf iSCSI-LUNs das proprietäre VMFS — ein Cluster-Filesystem, das mehrere ESXi-Hosts gleichzeitig auf dieselbe LUN schreiben lässt. Das ermöglicht vMotion, HA, DRS ohne extra File-Locking-Logik.

Predictable Performance. Eine LUN hat eine klare Größe und ein klares Performance-Profil. Keine Überraschungen durch “andere Workloads auf der gleichen Freigabe”.

Nachteile

Pro VM-Disk eine LUN ist nicht praktikabel. In großen Umgebungen mit Hunderten VMs wäre das LUN-Management überwältigend. Stattdessen: Eine große LUN, viele VMs darauf. Das macht Snapshots auf Storage-Ebene sperrig — ein TrueNAS-Snapshot der LUN umfasst alle VMs darauf.

Cluster-Koordination nötig. Mehrere Hypervisoren auf der gleichen LUN brauchen ein Cluster-Filesystem (VMFS) oder Cluster-LVM. Bei Proxmox ohne VMFS: pro Node eine LUN, manueller Failover.

Snapshot-Restore schwieriger. Wenn auf einer LUN 50 VMs liegen und Sie eine einzelne VM zurücksetzen wollen, müssen Sie den TrueNAS-Snapshot nicht restoren — sondern als read-only Klon mounten, die VM-Disk auslesen, ins laufende VMFS kopieren.

Komplexere Einrichtung. iSCSI braucht Initiator-Konfiguration auf jedem Hypervisor, Authentifizierung (CHAP), Target-Portal, LUN-Mapping, Multipath-Konfiguration. NFS ist im Vergleich “Pfad mounten und fertig”.

NFS im Detail

Vorteile

VMs sind Dateien. Eine .qcow2- oder .vmdk-Datei ist verschiebbar, kopierbar, einzeln backupbar. Das macht Storage-vMotion und manuelle Migrationen einfach: mv vm-100-disk-0.qcow2 und fertig.

Snapshots auf TrueNAS-Seite sind direkt zugänglich. Wenn Sie einen Dataset-Snapshot machen und später nur eine einzelne VM-Disk daraus retten wollen, ist das ein einfacher Datei-Zugriff im versteckten .zfs/snapshot/<name>/-Verzeichnis. Bei iSCSI wäre das deutlich aufwendiger.

Mehrere Hypervisoren ohne Cluster-Filesystem. NFS hat eingebaute Locking-Semantik (RPC). Drei ESXi können gleichzeitig auf einen NFS-Mount zugreifen, ohne dass ein VMFS-Pendant nötig ist. Bei Proxmox: drei Nodes mounten den gleichen NFS-Pfad, und VMs lassen sich live migrieren — ohne extra Cluster-Storage-Layer.

Einfach zu verstehen, einfach zu debuggen. Eine NFS-Freigabe ist menschenlesbar. Sie können ls auf dem Hypervisor machen und sehen die VM-Disks.

Thin-Provisioning gratis. Eine .qcow2-Datei wächst nur so groß, wie sie wirklich Daten enthält. Bei iSCSI-LUNs muss thin provisioning explizit auf Storage- und Hypervisor-Ebene konfiguriert sein.

Nachteile

File-Locking-Overhead. Jeder I/O auf einer NFS-Freigabe geht durch die NFS-Locking-Logik. Bei sehr vielen kleinen I/Os macht sich das messbar bemerkbar — auch wenn die Latenz im LAN typisch unter 1 ms liegt.

Eine langsame Freigabe macht alle VMs langsam. Wenn ein einzelner Hypervisor den NFS-Mount mit zu vielen Schreibvorgängen sättigt, leiden alle anderen Hypervisoren, die auf den gleichen Mount zugreifen. Bei iSCSI mit separaten LUNs ist die Isolation besser.

Performance bei kleinen synchronen Writes. NFS-Writes mit sync=always (was bei VM-Storage sinnvoll ist, um Konsistenz zu garantieren) hängen am ZFS-SLOG-Performance. Ohne dedicated SLOG-NVMe sind synchrone Writes deutlich langsamer als iSCSI mit Write-Cache.

Multipathing weniger geradlinig. NFS kennt kein klassisches MPIO. Hochverfügbarkeit auf NFS-Ebene wird über VRRP/CARP auf dem Storage-Layer abgebildet (TrueNAS HA-Pärchen) oder LACP-Bonds, nicht über mehrere Mount-Pfade. Performance-Load-Balancing über mehrere Links ist mit NFSv4.1 (pNFS) möglich, in der Praxis aber selten.

ESXi-Treiber-Eigenheiten. Manche älteren ESXi-Versionen hatten Probleme mit NFSv4 (Pflicht: NFSv3 oder spezifisch konfigurierter NFSv4.1). Auf aktuellen ESXi-Versionen weitgehend gelöst, aber lohnt sich Versionscheck.

Performance-Vergleich: Was misst man wirklich?

Häufige Aussage: “iSCSI ist 30% schneller als NFS.” Das ist eine Vereinfachung — die Wahrheit ist nuancierter:

Sequenzielle Reads/Writes (Backup-Jobs, Video-Streams): Praktisch kein Unterschied. Beide Protokolle sättigen 10 GbE etwa gleich. Bei 25/40/100 GbE wird der Storage-Pool (Disks, ARC) zum Bottleneck, nicht das Protokoll.

Random 4K Reads (VDI, Datenbanken): iSCSI hat einen leichten Vorteil — typisch 5–15% bei sonst gleicher Hardware. Auf Pool-Ebene viel wichtiger: NVMe vs. HDD, ARC-Größe, SLOG (für sync-writes).

Random 4K Writes (Datenbank-Schreiblast): Bei sync=always ist NFS oft langsamer — die SLOG-Performance limitiert. Mit sync=disabled schließt NFS auf, ist aber bei Stromausfall riskant.

Mixed VM-Workloads: In gemischten Mid-Range-Setups (TrueNAS H- oder M-Serie + 10/25 GbE) ist der Unterschied in der Praxis kleiner, als die Foren-Diskussion suggeriert. Der Pool-Design-Einfluss (NVMe-SLOG, Mirror vs. RAIDZ, ARC-Größe) ist deutlich größer als die Protokoll-Wahl.

Snapshots: Der unterschätzte Faktor

Ein wesentlicher Architektur-Unterschied steckt im Snapshot-Verhalten — und das hat im VM-Storage-Kontext massive Auswirkungen.

iSCSI-Snapshots

• TrueNAS-Snapshot der LUN umfasst alle VMs auf der LUN
• Restore eines Snapshots = Rollback der gesamten LUN → alle VMs werden zurückgesetzt
• Selektives Restore einer einzelnen VM: Clone-Mount, manuelles Auslesen
• Hypervisor-eigene Snapshots (VMware VMSnapshot, Proxmox-Snapshot) funktionieren parallel, sind aber separat

NFS-Snapshots

• TrueNAS-Snapshot des NFS-Datasets umfasst alle VM-Dateien
• Restore: Sie können einzelne .qcow2/.vmdk-Dateien aus dem .zfs/snapshot/-Pfad direkt zurückkopieren
• Hypervisor-Snapshots (VMware VMSnapshot, qcow2-Internal-Snapshots) ergänzen sich gut
• Selektives Restore ist einfacher

Für KMU-Setups ohne dedizierte Storage-Admins ist das ein starkes Argument für NFS — die Restore-Pfade sind verständlicher und weniger fehleranfällig.

Siehe auch TrueNAS Snapshot Schedule Best Practices und unseren spezifischen Artikel zu TrueNAS Snapshot-Strategien für VM-Storage.

Empfehlungen pro Hypervisor-Plattform

VMware vSphere / ESXi

Historisch: iSCSI mit VMFS — viele Bestandsumgebungen sehen so aus.

Aktuell: NFS hat aufgeholt. vSphere unterstützt NFSv4.1 stabil. Storage-vMotion zwischen NFS-Datastores funktioniert, Snapshots aus dem TrueNAS sind leichter zugänglich.

Empfehlung 2026:

• Neue Setups ohne FC-Historie: NFS für die Einfachheit, iSCSI mit Multipath wenn maximale Performance gefragt ist
• Bestandsumgebungen mit funktionierender iSCSI/VMFS-Welt: Nicht ohne Grund migrieren
• NVMe-oF/TCP ist die neue Empfehlung von TrueNAS für High-Performance — wenn ESXi-Version (8.0+) das unterstützt

Proxmox VE

Empfehlung: NFS für Einfachheit. Proxmox-Cluster-VMs lassen sich live zwischen Nodes migrieren, wenn alle den gleichen NFS-Mount nutzen.

Alternativ iSCSI mit LVM-thin für ZFS-fremde Setups — aber dann verlieren Sie die direkten Vorteile von ZFS-Snapshots, die das TrueNAS-Proxmox-Plugin automatisiert anbietet.

Seit dem offiziellen Proxmox-Plugin (TrueNAS 25.10) ist iSCSI mit ZFS-aware Snapshots aus dem Proxmox-UI möglich. Das ist für Proxmox-Setups ein starkes Argument für iSCSI — die Snapshot-Schwierigkeit oben fällt weg.

Linux KVM (libvirt)

Empfehlung: NFS für einfache Setups, iSCSI mit LVM für gemeinsame Storage in Cluster-Setups (Pacemaker, oVirt).

Microsoft Hyper-V

Hyper-V kann beides, aber SMB3 ist hier oft die natürlichere Wahl als NFS — Microsoft hat SMB3 stark optimiert für Hyper-V-Storage. iSCSI mit Cluster Shared Volumes (CSV) ist die enterprise-übliche Variante.

NVMe-oF: Die Zukunft macht beide alt

Sowohl iSCSI als auch NFS sind vor der SSD-Ära entwickelt worden. iSCSI ist 2003 ratifiziert, NFSv3 1995. Bei modernen NVMe-SSDs mit Mikrosekunden-Latenz fressen beide Protokolle einen erheblichen Anteil der theoretischen Performance auf.

NVMe-oF (NVMe over Fabrics) — insbesondere NVMe/TCP — adressiert das. Das Protokoll spricht direkt NVMe-Kommandos über Netzwerk, ohne den Block-Layer-Stack von iSCSI. Ergebnis: deutlich niedrigere Latenz, höhere IOPS.

• TrueNAS unterstützt NVMe-oF/TCP seit der 24.10 / 25.04 Linie (siehe TrueNAS-Proxmox-Plugin)
• VMware ESXi 8.0+ unterstützt NVMe-oF/TCP nativ
• Linux Kernel kann NVMe-oF/TCP seit Linux 5.0

Für neue All-NVMe-Storage-Pools (F-Serie, V-Serie) ist NVMe-oF/TCP in vielen Setups bereits die richtige Wahl gegenüber iSCSI.

Konkrete Entscheidungsmatrix

Szenario	Empfehlung
Proxmox-Cluster mit kleinem VM-Setup, KMU	NFS
Proxmox-Cluster mit TrueNAS-Plugin, ZFS-Snapshots aus UI	iSCSI (Plugin) oder NVMe-oF/TCP
VMware-Bestandsumgebung mit VMFS	iSCSI beibehalten
Neue VMware-Umgebung 2026, < 50 VMs	NFS
Neue VMware-Umgebung 2026, > 100 VMs Performance-kritisch	iSCSI mit Multipath, mittelfristig NVMe-oF/TCP
VDI mit hundert Boot-Storms morgens	iSCSI mit Multipath oder NVMe-oF
Datenbank-VMs mit Sync-Schreiblast	iSCSI mit dediziertem SLOG, oder NVMe-oF
Backup-Targets, Archiv-VMs	NFS (Einfachheit gewinnt)
Hyper-V	SMB3 oder iSCSI mit CSV

Praxis-Empfehlung von DATAZONE

Für mittelständische Setups mit TrueNAS + Proxmox ist unsere Default-Empfehlung 2026:

• NFS als Basis, wenn Sie keine besonderen Performance-Anforderungen haben
• iSCSI mit dem offiziellen TrueNAS-Proxmox-Plugin, wenn Sie ZFS-Snapshots aus dem Proxmox-UI haben wollen
• NVMe-oF/TCP für neue All-NVMe-Investitionen (F-Serie, V-Serie All-Flash)

Für VMware-Setups kommt es stark auf die Historie an — wer iSCSI/VMFS produktiv hat, sollte nicht ohne Grund migrieren. Wer neu plant, kann NFS in Erwägung ziehen oder direkt auf NVMe-oF setzen.

Fazit

iSCSI und NFS sind beide produktionsreif. Der Unterschied liegt weniger in der reinen Performance als in der Storage-Ergonomie: NFS macht Snapshots und einzelne VM-Restores einfach; iSCSI ist enger an Cluster-Filesystemen und Multipath-Setups gewachsen.

Für die meisten KMU-Setups sind die Argumente für NFS überwiegend — bis das offizielle TrueNAS-Proxmox-Plugin ins Spiel kommt, das die historischen Snapshot-Nachteile von iSCSI weitgehend behebt.

Und für die nächsten 3–5 Jahre: NVMe-oF/TCP schaut man besser zweimal an, bevor man neue All-NVMe-Setups noch klassisch mit iSCSI plant.

Quellen und weiterführende Artikel

• TrueNAS iSCSI Multipath für VMware
• TrueNAS-Proxmox-Plugin (offiziell, NVMe/TCP)
• TrueNAS Snapshot Schedule Best Practices
• TrueNAS Snapshot-Strategien für VM-Storage
• Ceph vs. ZFS — Wann was?
• TrueNAS Performance-Optimierung
• Proxmox Backup Server 4.0 Neuerungen