TrueNAS als Proxmox-Speicher: iSCSI mit Multipath und LVM einrichten ddd Diese Dokumentation zeigt die Einrichtung eines gemeinsamen iSCSI-Speichers für einen Proxmox-Cluster mit TrueNAS. Zwei getrennte SAN-Netze stellen die Speicherverbindungen bereit. Multipath bündelt die Zugriffswege auf dieselbe LUN, während Proxmox die VM-Datenträger über LVM verwaltet. Dokumentiert wurde ein Workshop mit drei Proxmox-Knoten. Die Anleitung enthält die sichtbaren Einrichtungsschritte, passende Screenshots und eine Einordnung der aufgetretenen Probleme. Am Ende folgen konkrete Optimierungstipps. Stand: 7. September 2026 · Umgebung: Proxmox VE 9.2.11 und TrueNAS Community Edition Ergebnis: Die iSCSI-Anbindung und zwei verfügbare Multipath-Pfade je Host sind dokumentiert. Das Verschieben einer VM-Festplatte auf TrueNAS war erfolgreich. Eine erfolgreiche VM-Migration und ein Ausfalltest sind in den Screenshots noch nicht belegt. Inhalt Netzwerk und IP-Adressen TrueNAS-Pool und iSCSI-LUN erstellen iSCSI-Portale und Initiatoren konfigurieren iSCSI in Proxmox einbinden Multipath einrichten und prüfen Gemeinsamen LVM-Speicher hinzufügen VM-Festplatte verschieben und Migration prüfen Prüfliste für die Abnahme Optimierungstipps für den Betrieb 1. Netzwerk und IP-Adressen für Proxmox und TrueNAS Das Managementnetz und die beiden Speichernetze sind getrennt. SAN1 verwendet das Netz 172.16.1.0/24, SAN2 das Netz 172.16.2.0/24. Die Managementadressen liegen im Netz 192.168.168.0/24. Adressübersicht des Workshop-Clusters System Management SAN1 SAN2 pve1 192.168.168.21 172.16.1.21 172.16.2.21 pve2 192.168.168.22 172.16.1.22 172.16.2.22 pve3 192.168.168.23 172.16.1.23 172.16.2.23 TrueNAS 192.168.168.67 172.16.1.67 172.16.2.67 Auf TrueNAS übernimmt enp2s0f0 das Management, ens1f0np0 SAN1 und enp2s0f1 SAN2. Die SAN-Adressen von pve2 und pve3 werden durch die später sichtbaren iSCSI-Verbindungen bestätigt; ihre vollständigen finalen Schnittstellendateien sind nicht abgebildet. TrueNAS: Die zweite SAN-Schnittstelle erhält eine statische Adresse im separaten Speichernetz. SAN-Schnittstellen auf Proxmox konfigurieren Die spätere Konfiguration von pve1 verwendet nic1 für SAN1 und nic2 für SAN2. Das Standardgateway 192.168.168.1 bleibt am Managementnetz über vmbr0. Für die SAN-Schnittstellen ist kein Gateway eingetragen. auto nic1 iface nic1 inet static address 172.16.1.21/24 auto nic2 iface nic2 inet static address 172.16.2.21/24 Die spätere Konfiguration zeigt beide SAN-Netze zusätzlich zur Management-Bridge. Ein früher Ping scheitert mit „Destination Host Unreachable“. Nach den Anpassungen sind erfolgreiche Antworten von beiden TrueNAS-SAN-Adressen auf pve1 und pve2 sichtbar. Auch pve3 erreicht dokumentierte SAN-Ziele. Diese kurzen Tests bestätigen die Erreichbarkeit, aber noch keine Leistung oder Stabilität unter Last. 2. TrueNAS-Pool und iSCSI-LUN erstellen ZFS-Mirror aus zwei SSDs anlegen Unter Storage → Create Pool wird der Pool Mirror erstellt. Er besteht aus einem Mirror-VDEV mit zwei als SSD erkannten Laufwerken von jeweils 931,51 GiB. Eine Verschlüsselung ist in der gezeigten Konfiguration nicht aktiviert. Die Poolerstellung löscht die ausgewählten Datenträger. Vor einer Wiederholung müssen deshalb Laufwerksauswahl und vorhandene Daten geprüft werden. Poolplanung: ein Mirror-VDEV mit zwei SSDs. Nach der Erstellung zeigt TrueNAS etwa 899,25 GiB nutzbare Kapazität und den Zustand „Online, no errors“. Ein Scrub ist sonntags um 00:00 Uhr geplant. Auto TRIM ist ausgeschaltet; Temperaturdaten sind nicht verfügbar. Dataset und Zvol mit 512 GiB erstellen Unter Shares → Block (iSCSI) Shares Targets → Wizard wird ein neues Target vorbereitet. Im Pool entsteht das Dataset Mirror/iscsi. Der Assistent erstellt darin ein neues Blockgerät mit 512 GiB. Für die LUN sind 512 GiB und zuletzt das Plattformprofil „Modern OS“ ausgewählt. Das Profil zeigt eine Extent-Blockgröße von 4 KiB. Diese Angabe ist nicht mit der ZFS-Eigenschaft volblocksize gleichzusetzen. Der später sichtbare Gerätepfad lautet zvol/Mirror/iscsi/iscsi. 3. iSCSI-Portale und Initiatoren konfigurieren Das TrueNAS-Target wird über 172.16.1.67 und 172.16.2.67 erreichbar gemacht. Beide Portal-Adressen führen zur selben LUN. Mehrere Portal-Adressen bilden die Grundlage für die späteren Multipath-Verbindungen. Die eindeutigen Initiator-Namen der Proxmox-Knoten lassen sich auf jedem Host auslesen: cat /etc/iscsi/initiatorname.iscsi Im Workshop werden alle drei Initiatoren im TrueNAS-Assistenten hinterlegt. Danach wird der iSCSI-Dienst gestartet; die Option für den automatischen Start ist ausgewählt. Zwei SAN-Portale und die Initiatoren der drei Proxmox-Knoten werden dem Target zugeordnet. Die spätere Übersicht zeigt das Target iscsi mit LUN-ID 0, Authentifizierung NONE und sechs Verbindungen: jeweils eine Verbindung pro Host und SAN-Netz. Es sind keine zusätzlichen „Authorized Networks“ eingetragen; die Initiatorliste ist davon getrennt zu betrachten. Die Target-Übersicht bestätigt zwei Verbindungen je Proxmox-Knoten. 4. TrueNAS-iSCSI-Speicher in Proxmox einbinden Unter Datacenter → Storage → Add → iSCSI wird die Verbindung hinzugefügt: ID: iscsi-portal Portal: 172.16.1.67 Target: iqn.2005-10.org.freenas.ctl:iscsi Nodes: alle Knoten Enable: aktiviert Use LUNs directly: deaktiviert Die iSCSI-Verbindung wird als Grundlage für den späteren LVM-Speicher eingerichtet. Nach der Einrichtung ist iscsi-portal aktiv. Der Inhaltstyp none passt zur Nutzung als Basis für LVM. Vor der Multipath-Einrichtung erscheinen zwei Geräte mit jeweils 512 GiB. Sie stellen zwei Wege zu derselben LUN dar und dürfen nicht als unabhängige Datenträger verwendet werden. 5. iSCSI-Multipath auf den Proxmox-Knoten einrichten Multipath-Werkzeuge installieren und Sitzungen prüfen Auf allen drei Hosts wird die Installation der Multipath-Werkzeuge angestoßen: apt-get install multipath-tools -y Auf pve1 und pve2 ist der Installationsabschluss sichtbar. Auf pve3 bestätigen die späteren Abfragen die Verfügbarkeit. Die iSCSI-Sitzungen werden mit folgendem Befehl geprüft: iscsiadm -m session Auf pve3 sind Verbindungen zu beiden Portalen über TCP-Port 3260 sichtbar. Dieselbe LUN über ihre WWID identifizieren Im gezeigten Beispiel heißen die beiden Pfadgeräte auf pve3 /dev/sdd und /dev/sde. Ihre Identität wird so abgefragt: /lib/udev/scsi_id -g -u -d /dev/sdd /lib/udev/scsi_id -g -u -d /dev/sde Beide liefern die WWID 36589cfc00000005cf4f3f236e1d7b5b0. Die Gerätenamen können auf anderen Hosts oder nach einem Neustart abweichen. Vor einer Übernahme der Befehle müssen die tatsächlich vorhandenen Geräte geprüft werden. WWID registrieren und Multipath kontrollieren multipath -a 36589cfc00000005cf4f3f236e1d7b5b0 multipath -r multipath -ll Die Ausgabe zeigt ein logisches Multipath-Gerät und zwei Pfade mit „active ready running“. Vergleichbare abschließende Ausgaben sind auf allen drei Hosts sichtbar. Eine aktive und eine weitere verfügbare Pfadgruppe sind dokumentiert. Ein praktischer Ausfalltest wurde damit noch nicht nachgewiesen. Wichtige Korrektur: Konfiguration und WWID-Datei trennen Im Workshop wird zwischenzeitlich ein multipaths { … }-Block mit einem Alias in /etc/multipath/wwids eingetragen. Ein solcher Block gehört in die Multipath-Konfiguration, üblicherweise /etc/multipath.conf. Die WWID-Datei dient der Registrierung der Geräte und wird über die Multipath-Werkzeuge gepflegt. Später wird die WWID erneut hinzugefügt und die Datei zwischen Hosts kopiert. Obwohl die abschließenden Geräteausgaben erfolgreich sind, ist der endgültige Dateiinhalt nicht sichtbar. Die Bereinigung muss deshalb vor einer Abnahme geprüft werden. iSCSI-Timeouts auf tatsächliche Wirksamkeit prüfen Auf pve3 wird in /etc/iscsi/iscsid.conf folgende Einstellung gezeigt: node.session.timeo.replacement_timeout = 15 Eine spätere Sitzungsdetailansicht zeigt weiterhin Recovery Timeout: 120. Das deutet darauf hin, dass die geänderte Vorgabe in der betrachteten Sitzung noch nicht wirksam war. Konfigurationsdatei, gespeicherte Verbindungseinträge und aktive Sitzungen müssen gemeinsam geprüft werden. 6. Gemeinsamen LVM-Speicher auf der iSCSI-LUN hinzufügen Unter Datacenter → Storage → Add → LVM wird der Speicher truenas angelegt. Als Basisspeicher dient iscsi-portal, als Basisvolume die LUN 0. Die Volume Group erhält im Workshop den Namen pve. Zugelassen sind VM-Festplatten und Container. Bei der ursprünglichen Anlage ist „Shared“ noch nicht aktiviert. Die Ausgabe von pvs auf pve1 ordnet die Volume Group dem Multipath-Gerät unter /dev/mapper/… zu. Proxmox zeigt etwa 549,75 GB Gesamtkapazität, entsprechend ungefähr 512 GiB. Später werden Shared und Wipe Removed Volumes aktiviert. Die Option Allow Snapshots as Volume-Chain bleibt eingeschaltet. Die spätere Bearbeitung markiert den LVM-Speicher als gemeinsam genutzt. Shared stellt keine Speicherverbindung her. Die Einstellung beschreibt einen bereits von mehreren Knoten erreichbaren Speicher. Alle Hosts müssen dieselbe LUN und Volume Group erkennen. Die Oberfläche kennzeichnet Volume-Chain-Snapshots als Technology Preview. QCOW2 auf LVM ist in diesem Zusammenhang nicht automatisch falsch: Das Proxmox-Administrationshandbuch beschreibt diese Funktion für neuere Versionen. Bei bereits vorhandenen abhängigen Volumes darf die Option nicht unvorbereitet deaktiviert werden. 7. VM-Festplatte auf TrueNAS verschieben und Migration prüfen Als Beispiel dient VM 100 (TRMM) mit 8 GiB RAM, vier CPU-Kernen, CPU-Typ host, OVMF/UEFI und einer 32-GiB-Systemfestplatte. Die VM verwendet einen VirtIO-SCSI-single-Controller und ein VirtIO-Netzwerkgerät an vmbr0. Systemfestplatte auf den LVM-Speicher verschieben In der Hardwareansicht wird für scsi0 die Aktion zum Verschieben des Speichers geöffnet. Ausgewählt sind das Ziel truenas, das Format qcow2 und das Löschen der Quelle nach dem Verschieben. Die 32-GiB-Systemfestplatte wird von lokalem ZFS auf den TrueNAS-LVM-Speicher verschoben. Das Zielvolume lautet truenas:vm-100-disk-0.qcow2. Die spätere Aufgabenliste bestätigt den Verschiebevorgang mit OK. Um 16:48 Uhr liegt die EFI-Disk noch auf local-zfs. Ein weiterer erfolgreicher Verschiebetask ist sichtbar, dessen betroffenes Volume jedoch nicht eindeutig belegt ist. Warum die VM-Migration noch offen ist Mehrere Offline-Migrationen von pve1 nach pve2 enden mit Error: migration aborted. Frühere Dialoge warnen vor lokalen Datenträgern. Nach dem Aktivieren von „Shared“ zeigt der abgebildete Dialog diese Warnungen nicht mehr. Vor der Shared-Korrektur behandelt der Dialog auch die Festplatte auf truenas als lokalen Speicher. Die konkrete Abbruchursache lässt sich aus den Screenshots nicht bestimmen. Dafür ist die vollständige Ausgabe eines fehlgeschlagenen Migrationstasks erforderlich. Eine bestimmte Multipath-, CPU- oder VM-Einstellung als Ursache zu benennen, wäre ohne dieses Log spekulativ. Letzter dokumentierter Stand: Klonvorgang läuft Der letzte Screenshot um 16:55 Uhr zeigt einen laufenden Klonvorgang von VM 111 mit etwa 21 Prozent Fortschritt. Das Zielvolume gehört zu VM 101 auf truenas. Ein Abschluss ist nicht abgebildet. Der im Hintergrund erfolgreiche Replikationsjob von VM 111 nach pve2 bestätigt weder den Klonabschluss noch die Migration von VM 100. 8. Prüfliste für die Abnahme des gemeinsamen Speichers Auf jedem Proxmox-Knoten sind beide TrueNAS-Portale verbunden. Alle Knoten erkennen dieselbe WWID und zwei fehlerfreie Multipath-Pfade. Die gemeinsame Volume Group ist über das Multipath-Gerät erreichbar. Multipath-Konfiguration und WWID-Registrierung sind korrekt getrennt. Die gewünschten iSCSI-Timeouts sind in den verwendeten Verbindungen wirksam. Die Speicherorte sämtlicher VM-Disks einschließlich EFI sind dokumentiert. Eine Offline-Migration endet mit OK; die VM startet und funktioniert auf dem Zielhost. Ein kontrollierter Test bestätigt den Weiterbetrieb beim Ausfall eines einzelnen SAN-Pfads. Nach einem Host-Neustart sind Speicher und beide Verbindungen automatisch verfügbar. Ein unabhängiges Backup wurde erfolgreich wiederhergestellt und geprüft. 9. Optimierungstipps für Proxmox, TrueNAS und iSCSI-Multipath Zuerst Konfiguration und Migration abschließen Multipath-Dateien vereinheitlichen: Prüfe die Konfiguration und die registrierten WWIDs auf allen Hosts. Vergleiche vorhandene Inhalte, bevor Dateien überschrieben werden. Migrationslog auswerten: Sichere die vollständige Task-Ausgabe und behebe die dort genannte Ursache. Wiederholte Versuche ohne Logauswertung liefern wenig zusätzliche Erkenntnis. Alle VM-Datenträger berücksichtigen: Prüfe neben der Systemfestplatte auch EFI-, gegebenenfalls TPM- und weitere Disks. Timeouts kontrolliert übernehmen: Kläre die Abweichung zwischen den konfigurierten 15 Sekunden und den sichtbaren 120 Sekunden. Änderungen an bestehenden Speicherverbindungen gehören in ein Wartungsfenster. Ausfallsicherheit praktisch nachweisen Unabhängige SAN-Wege verwenden: Getrennte Subnetze sollten durch geeignete physische Wege ergänzt werden. Prüfe Adapter, Verkabelung und Switches auf gemeinsame Ausfallpunkte. Die TrueNAS-Netzwerkempfehlungen erläutern die Verwendung zusätzlicher iSCSI-Portale. Pfadwechsel testen: Unterbrich mit einer Test-VM und laufenden Ein-/Ausgaben jeweils nur einen SAN-Pfad. Prüfe anschließend auch dessen Wiederkehr und einen Host-Neustart. TrueNAS-Ausfall einplanen: Mirror und Multipath schützen gegen unterschiedliche Teilfehler. Der vollständige Ausfall eines einzelnen TrueNAS-Systems erfordert weiterhin einen Wiederanlaufplan und unabhängige Sicherungen. Leistung, Wartung und Sicherheit verbessern Vorschaufunktionen gezielt testen: Prüfe bei Volume-Chain-Snapshots insbesondere Erstellung, Löschen, Backup, Restore und Migration mit der eingesetzten Version. Eindeutige Namen wählen: Bei künftigen Einrichtungen lässt sich eine Volume Group wie vg_truenas_iscsi leichter zuordnen als pve. Bestehende Gruppen nicht ohne Prüfung ihrer Referenzen umbenennen. Leistung messen: Erfasse Durchsatz, IOPS und Latenz in einer Test-VM, bevor MTU, Pfadverteilung oder ZFS-Parameter geändert werden. Jumbo Frames benötigen eine durchgängig passende Netzwerkkonfiguration. SSD-Wartung ergänzen: Prüfe TRIM-Unterstützung und Laufwerksüberwachung. Im dokumentierten Stand ist Auto TRIM ausgeschaltet; Temperaturdaten fehlen. Überwache außerdem Poolkapazität, Speicherfehler und ausgefallene Pfade. Zugriffe begrenzen: Behalte eindeutige Initiatorlisten bei und beschränke die SAN-Erreichbarkeit auf die vorgesehenen Hosts. Prüfe CHAP oder Mutual CHAP als zusätzliche Authentifizierung. CHAP verschlüsselt den Datenverkehr nicht. Weitere Informationen enthält die TrueNAS-iSCSI-Dokumentation. Backups unabhängig speichern: Sichere VMs außerhalb der produktiven LUN und dokumentiere einen erfolgreichen Restore mit VM-Start und Anwendungstest. Mirror, Snapshots und Replikation ersetzen dieses Backup nicht.
