TrueNAS als Proxmox-Speicher: iSCSI mit Multipath und LVM einrichten dddVideo zum Artikel: Die Einrichtung wird im begleitenden Livestream zu Proxmox, TrueNAS und iSCSI-Multipath gezeigt. 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. EineBei erfolgreicheder VM-Einrichtung wurde zunächst der Haken bei „Shared“ vergessen. Die fehlgeschlagene Migration lag an einem noch eingerichteten ZFS-Replikationsjob. Nach Aktivierung von Shared, Entfernung der bisherigen ZFS-Replikationsjobs und einÜbernahme aller VM-Disks einschließlich EFI und gegebenenfalls TPM liefen alle Migrationen tadellos. Dieses abschließende Ergebnis ergänzt die Screenshots durch die nachträgliche Bestätigung aus dem Workshop. Ein Ausfalltest sindist in den Screenshots nochweiterhin nicht belegt.dokumentiert. 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. SSH-Loginprobleme nach manuellen Verbindungen zwischen den Knoten Während der Einrichtung können bei manuellen SSH-Verbindungen zwischen den Nodes Loginprobleme auftreten, beispielsweise durch widersprüchliche gespeicherte Hostschlüssel. Eine manuelle Verbindung verursacht nicht grundsätzlich einen Fehler; entscheidend ist die konkrete SSH-Meldung. Bei einem veralteten Hostschlüsseleintrag lässt sich beispielsweise so vorgehen: Zunächst den aktuellen Fingerprint auf dem Zielknoten über eine vertrauenswürdige Konsole anzeigen und mit der SSH-Meldung vergleichen: ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub Nur wenn der Schlüsselwechsel geklärt ist und die Fehlermeldung auf /root/.ssh/known_hosts verweist, auf dem Quellknoten die betroffenen Einträge entfernen. Beispiel für pve2: ssh-keygen -f /root/.ssh/known_hosts -R pve2 ssh-keygen -f /root/.ssh/known_hosts -R 192.168.168.22 ssh root@pve2 Beim erneuten Verbindungsaufbau den angezeigten Fingerprint prüfen. Bei abweichendem Hostnamen oder Dateipfad die Angaben aus der tatsächlichen Fehlermeldung verwenden; nicht pauschal die gesamten Known-Hosts-Dateien löschen. Bei veralteten Proxmox-Hostschlüsseldaten, etwa nach erneutem Beitritt eines Nodes mit gleichem Namen oder gleicher IP, kann auf dem betroffenen Zielknoten außerdem Folgendes helfen: pvecm updatecerts Proxmox verwendet versionsabhängig eigene Hostschlüsseldateien beziehungsweise explizites Host-Key-Pinning. Ein erfolgreicher manueller SSH-Login allein bestätigt daher nicht jede von Proxmox verwendete SSH-Verbindung. Siehe die Proxmox-Clusterdokumentation zur Rolle von SSH. Bei „Permission denied (publickey)“ stattdessen die Anmeldung mit Schlüsseln und die Zugriffsrechte prüfen; das Entfernen eines Hostschlüsseleintrags behebt diesen anderen Fehler nicht. 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 istwurde der Haken bei „Shared“ nochvergessen; nichtdies aktiviert.wurde später korrigiert. 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. WarumMigrationsfehler diegelöst: Shared, ZFS-Replikation und alle VM-MigrationDisks noch offen istprüfen 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 konkreteUrsache Abbruchursachewurde lässtim sichweiteren Workshop-Verlauf geklärt: Für die betroffene VM war noch ein ZFS-Replikationsjob eingerichtet. Dieser verbliebene Job verursachte die fehlgeschlagene Migration. Zusätzlich war bei der Anlage des LVM-Speichers zunächst der Haken bei „Shared“ vergessen worden. Für den Wechsel auf den gemeinsamen iSCSI-Speicher wurden deshalb folgende Punkte umgesetzt: Shared aktivieren: Den tatsächlich auf allen Knoten erreichbaren LVM-Speicher als gemeinsam genutzt markieren. Keine bisherigen ZFS-Replikationsjobs zurücklassen: Die für die umgestellte VM eingerichteten Jobs unter „Replication“ entfernen und deren Entfernung abwarten. Die native lokale ZFS-Replikation wird für die nun gemeinsam genutzten iSCSI-Disks nicht benötigt. Alle Disks migrieren: Neben der System- und den Datenfestplatten auch die EFI-Disk und eine gegebenenfalls vorhandene TPM-State-Disk auf den gemeinsamen Speicher verschieben. Bestehende EFI- und TPM-Datenträger übernehmen, nicht neu erstellen. Danach liefen alle Migrationen tadellos. Dieses Ergebnis wurde nachträglich aus dendem Workshop bestätigt; die eingebetteten Screenshots nichtzeigen bestimmen. Dafür istnoch die vollständigevorherigen Ausgabe eines fehlgeschlagenen Migrationstasks erforderlich. Eine bestimmte Multipath-, CPU- oder VM-Einstellung als Ursache zu benennen, wäre ohne dieses Log spekulativ.Zwischenstände. 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 erfolgreichesichtbare Replikationsjob von VM 111 nach pve2 bestätigtgehört wedernoch denzum aufgenommenen Zwischenstand. Der Klonabschluss nochist nicht abgebildet; die Migrationanschließend vonfehlerfrei VMlaufenden 100.Migrationen wurden nachträglich bestätigt. 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. DieShared Speicherorteist sämtlicheraktiviert; auf allen Knoten ist tatsächlich derselbe Speicher erreichbar. Für die auf iSCSI umgestellten VMs sind keine bisherigen ZFS-Replikationsjobs mehr eingerichtet. Sämtliche VM-Disks einschließlich EFI sindund dokumentiert.gegebenenfalls TPM liegen auf dem gemeinsamen Speicher. 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 ZuerstBewährte Konfiguration undfür Migrationweitere abschließenMigrationen übernehmen Multipath-Dateien vereinheitlichen: Prüfe die Konfiguration und die registrierten WWIDs auf allen Hosts. Vergleiche vorhandene Inhalte, bevor Dateien überschrieben werden. MigrationslogShared auswerten:und Replikationsjobs prüfen: SichereIm dieWorkshop war Shared zunächst vergessen worden; ein verbliebener ZFS-Replikationsjob verursachte den Migrationsabbruch. Bei weiteren Umstellungen Shared aktivieren und bisherige ZFS-Replikationsjobs der betroffenen VM entfernen. Bei neuen Fehlern zusätzlich das vollständige Task-AusgabeMigrationslog und behebe die dort genannte Ursache. Wiederholte Versuche ohne Logauswertung liefern wenig zusätzliche Erkenntnis.auswerten. Alle VM-Datenträger berücksichtigen: PrüfeVerschiebe neben der Systemfestplatte auch Daten-, EFI-, und gegebenenfalls TPM-State-Disks undauf weitereden Disks.gemeinsamen Speicher. 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. Round Robin aktivieren: beide gleichwertigen SAN-Pfade nutzen Round Robin verteilt I/O reihum auf die Pfade einer aktiven Pfadgruppe. Bei gleichwertigen Verbindungen kann dies beide SAN-Links besser auslasten. Eine Verdopplung der Leistung ist nicht garantiert; service-time kann bei unterschiedlich schnellen oder belasteten Wegen günstiger sein. Der gezeigte Stand hat je Pfad eine eigene Gruppe. Der Selektor allein genügt daher nicht. Nur wenn beide Wege gleichzeitig gleichwertig nutzbar sind, eignet sich multibus für eine gemeinsame Gruppe. Bei ALUA- oder Active/Passive-Systemen die herstellergerechte Gruppierung beibehalten. Auf jedem Node den bestehenden Eintrag dieser LUN in /etc/multipath.conf ergänzen; übrige Konfiguration erhalten: multipaths { multipath { wwid 36589cfc00000005cf4f3f236e1d7b5b0 path_grouping_policy multibus path_selector "round-robin 0" rr_weight uniform rr_min_io_rq 1 } } rr_min_io_rq 1 bewirkt bei request-basiertem Multipath einen Wechsel nach einer I/O-Anforderung. Das Beispiel verändert keinen Gerätealias. Im Wartungsfenster zunächst die aufgelöste Konfiguration auf Fehler prüfen, dann neu laden: multipath -t multipathd reconfigure multipath -ll Erwartet: round-robin 0 und beide gesunden Pfade in derselben aktiven Gruppe. Danach Durchsatz, Latenz und Pfadausfall mit einer Test-VM prüfen. Die Option ist eine Optimierungsempfehlung, kein im Workshop belegter Änderungsschritt. Parameterreferenz: Debian-Handbuch zu multipath.conf.
