TrueNAS iSCSI Multipath für VMware vSphere

Wer 2026 produktive VMware-Workloads auf einem TrueNAS-System ablegt, sollte iSCSI nicht über einen einzelnen Pfad betreiben. Eine defekte SFP+-Optik, ein Firmware-Reboot des Switches oder ein gezogenes DAC-Kabel reicht aus, um sämtliche VMs auf dem Datastore in einen All-Paths-Down-Zustand zu versetzen. Multipath I/O, kurz MPIO, löst das Problem auf Storage-Ebene — sauber konfiguriert, ohne LACP, ohne MC/S und ohne herstellerspezifische Treiber.

Dieser Artikel zeigt, wie Sie zwischen TrueNAS SCALE 25.04 und VMware vSphere 8 U3 eine echte aktive Multipath-Verbindung aufbauen. Wir behandeln die TrueNAS-Seite mit Portal-Bindung und Target-Konfiguration, die ESXi-Seite mit Static Targets und Path Selection Policy sowie die Verifikation per vmkping und das IOPS-Tuning pro Pfad.

Warum MPIO und nicht LACP?

In SMB-Umgebungen taucht regelmäßig die Frage auf, warum man nicht einfach zwei 10GbE-Ports auf TrueNAS bündelt und ESXi den Rest erledigen lässt. Die Antwort liegt im Hashing: LACP verteilt Datenströme anhand von Source-/Destination-Tupeln. Eine einzelne iSCSI-Session zwischen einem ESXi-Initiator und einem TrueNAS-Target ergibt aber immer dasselbe Tupel — der gesamte Traffic landet auf einem physikalischen Link. Die zweite Leitung ist reines Standby.

Echtes Multipathing trennt die Pfade dagegen logisch: Jeder ESXi-VMkernel-Adapter spricht über sein eigenes Subnetz mit einem dedizierten TrueNAS-Portal. Das ergibt zwei voneinander unabhängige TCP-Sessions, die der VMware Native Multipathing Plugin im Round-Robin-Modus parallel füttert. Bei einem Link-Ausfall greift die Pfadüberwachung in Sekundenbruchteilen, ohne dass die VMs es merken.

TrueNAS-Seite: Portal mit zwei IPs anlegen

Auf dem TrueNAS-System konfigurieren Sie zwei dedizierte Storage-Netze. Bewährt hat sich ein Schema mit nicht-routbaren /29-Subnetzen pro Pfad, jeweils an einen eigenen physischen Switch angebunden. Beispiel:

Komponente	Pfad A	Pfad B
TrueNAS NIC	enp4s0f0	enp4s0f1
TrueNAS IP	10.20.10.10/29	10.20.20.10/29
Switch	Core-A	Core-B
ESXi vmk	vmk2	vmk3
ESXi IP	10.20.10.20/29	10.20.20.20/29
MTU	9000	9000

Im Web-UI navigieren Sie zu Shares — Block Shares (iSCSI) — Portals und legen ein Portal an, das beide IPs listet. Wichtig: Es handelt sich um EIN Portal mit zwei Adressen, nicht um zwei getrennte Portals. Discovery Auth bleibt für interne Pfade üblicherweise auf “None”, CHAP nur bei mandantengetrennten Setups.

Anschließend definieren Sie unter Targets ein neues Target und ordnen es genau diesem Portal sowie der vorbereiteten Initiator-Gruppe Ihres ESXi-Clusters zu. Als Extent verwenden Sie idealerweise ein ZFS-Volume (zvol) mit logischer Blockgröße 16K für gemischte VM-Workloads.

zfs create -V 4T -b 16K -o compression=lz4 -o sync=always tank/iscsi-vmw01

Die Option sync=always ist bei VMware Pflicht: Ohne sie meldet TrueNAS Schreibvorgänge als bestätigt, bevor sie persistent im Pool gelandet sind, was bei einem Stromausfall zu inkonsistenten VMDKs führen kann. Im Gegenzug brauchen Sie ein schnelles SLOG-Gerät, etwa eine Optane- oder Enterprise-NVMe mit Power-Loss-Protection.

ESXi-Seite: VMkernel und Port-Binding

Auf den ESXi-Hosts erzeugen Sie pro Pfad einen eigenen VMkernel-Adapter mit aktiviertem iSCSI-Service. Jeder vmk-Adapter erhält genau einen physischen Uplink in seiner Portgruppe — die anderen werden unter “Override” auf “Unused” gesetzt. Das ist die Voraussetzung für korrektes Port-Binding und verhindert, dass ESXi die Pfade über einen gemeinsamen Uplink zusammenfasst.

Anschließend aktivieren Sie den Software iSCSI Adapter und binden vmk2 sowie vmk3 explizit daran. Unter Static Discovery tragen Sie die beiden TrueNAS-Portal-IPs ein — nicht über Dynamic Discovery, sondern jede IP einzeln, damit ESXi sofort zwei Pfade zum selben Target sieht.

Vor dem Rescan verifizieren Sie die L2-Erreichbarkeit jedes Pfads mit Jumbo-Frames:

vmkping -I vmk2 -d -s 8972 10.20.10.10
vmkping -I vmk3 -d -s 8972 10.20.20.10

Antworten beide Tests erfolgreich, stimmen MTU und VLAN-Konfiguration auf der gesamten Strecke. Schlägt einer fehl, liegt das Problem fast immer am Switch-Port oder an einer falschen MTU im vSwitch — niemals direkt am TrueNAS-Portal.

Path Selection Policy: Round Robin mit IOPS-Tuning

Nach dem Rescan zeigt der Datastore zwei Pfade. Per Default setzt VMware bei generischen iSCSI-Targets oft die Policy “Most Recently Used” (MRU) — das bedeutet einen aktiven Pfad und einen Standby. Für TrueNAS stellen Sie auf Round Robin (VMW_PSP_RR) um, idealerweise per Claim Rule, damit neue LUNs automatisch korrekt eingebunden werden.

Der zweite Schritt ist das IOPS-Limit pro Pfad. Default sind 1000 I/Os je Pfad, bevor ESXi umschaltet — für Latenz-sensitive VMs zu hoch. Bei 10GbE-Multipath bewährt sich ein Wert von 1:

esxcli storage nmp psp roundrobin deviceconfig set \
  --device=naa.6589cfc000000xxxxxxxxxxxxxxxxxxx \
  --iops=1 --type=iops

Damit verteilt ESXi jeden einzelnen I/O abwechselnd über beide Pfade. Der CPU-Overhead ist auf modernen Xeon- oder EPYC-Hosts vernachlässigbar, der Durchsatzgewinn unter Last dagegen deutlich messbar. Mehr Hintergrund zu solchen Tuning-Entscheidungen finden Sie in unserer Virtualisierungsberatung.

Verifikation und Failover-Test

Vor der Produktivnahme gehört jeder MPIO-Aufbau auf den Prüfstand. Ein realistisches Testprotokoll umfasst:

Test	Methode	Erwartung
Beide Pfade aktiv	esxcli storage nmp device list	State: active für vmhba64:C0:T0 und C1:T0
Lastverteilung	esxtop — u, F — Pfad-Stats	Beide Pfade tragen IOPS
Switch-Ausfall A	Core-Switch A neustarten	Kein VM-Hänger, Pfad A geht auf “dead”, B trägt 100%
NIC-Failover TrueNAS	Kabel an enp4s0f0 ziehen	Identisches Verhalten, alarmierter Pfad
Wiederherstellung	Kabel/Switch zurück	Pfad geht automatisch zurück auf “active”

Die Failover-Zeit liegt bei sauberem Setup unter zwei Sekunden — weit unterhalb der typischen VM-Timeout-Schwellen. Wer eine grafische Auswertung der Pfad-Auslastung möchte, kann zusätzlich TrueNAS per SNMP oder NetData an ein zentrales Monitoring anbinden.

Häufige Stolpersteine

In der Praxis sehen wir immer wieder dieselben Fehler: VMkernel-Adapter mit mehreren aktiven Uplinks, gemeinsame Subnetze für beide Pfade, fehlendes Jumbo-Frame-Setup auf den Switch-Trunks oder ein TrueNAS-Pool ohne SLOG bei aktivem sync=always. Auch CHAP-Konfigurationen, die nur auf einer Seite hinterlegt sind, führen zu sporadisch “tot” gemeldeten Pfaden, die ESXi dann minutenlang nicht reaktiviert.

Ein weiterer Klassiker ist die Annahme, dass MPIO automatisch auch die Backup-Strecke abdeckt. Tut es nicht — Veeam- oder Proxmox-Backup-Datenströme laufen über andere Sessions und brauchen ein eigenes Konzept, etwa per Storage-Netz-Trennung oder dediziertem Backup-Portal.

Fazit

Multipath I/O auf TrueNAS ist mit überschaubarem Aufwand realisierbar und hebt die Verfügbarkeit Ihrer VMware-Storage-Anbindung auf das Niveau, das produktive Workloads 2026 verlangen. Zwei Subnetze, zwei Switches, zwei VMkernel — mehr braucht es nicht für echte Link-Redundanz und doppelten Durchsatz.

DATAZONE unterstützt Sie bei der Planung, Implementierung und dem Failover-Test Ihrer TrueNAS-VMware-Storage-Architektur — von der Auswahl der NIC- und SLOG-Hardware bis zur Inbetriebnahme im Produktivcluster. Sprechen Sie uns an, wenn Sie Ihre Storage-Verfügbarkeit auf den nächsten Schritt heben möchten.