NVMe over TCP in vSphere: Anforderungen, Einrichtung auf ESX und wann es iSCSI überlegen ist

Was NVMe over TCP in vSphere voraussetzt

vSphere unterstützt NVMe over TCP (NVMe/TCP) ab ESXi 7.0 Update 3, und ESXi 8.x und ESX 9.x führen es als einen von drei Transporten für gemeinsam genutzten Speicher über NVMe over Fabrics (NVMe-oF), neben Fibre Channel und RDMA (RoCE v2). Broadcoms Handbuch vSphere Storage zu 9.0, aktualisiert am 24. August 2026, und seine Fassung zu 9.1, aktualisiert am 12. Oktober 2026, nennen, was ein Host braucht: ein NVMe-Speicherarray mit Unterstützung für den Transport NVMe over TCP, einen kompatiblen ESX-Host, einen Ethernet-Adapter, einen Software-Adapter für NVMe over TCP und einen NVMe-Controller, den „Sie hinzufügen müssen“, nachdem der Software-Adapter konfiguriert ist. Broadcom nennt den Hypervisor ab Version 9.0 ESX und bis 8.x ESXi.

Der Software-Adapter wird an einen VMkernel-Adapter gebunden, der mit dem Dienst NVMe over TCP markiert ist. Namespaces auf dem Array erscheinen als Speichergeräte und werden als VMFS-Datastores formatiert. Das Handbuch führt außerdem vVols über NVMe-oF ab vSphere 8.0 auf, doch Broadcoms KB 401070 kündigt vVols ab VCF und VVF 9.0 ab und stellt alle vVol-Zertifizierungen für 9.0 ein; planen Sie Speicher über NVMe over TCP unter 9.x also als VMFS. Das High-Performance Plug-in (HPP) übernimmt das Multipathing, und das Native Multipathing Plug-in (NMP), das für iSCSI genutzt wird, kann keine NVMe-oF-Ziele beanspruchen. VMwares Performance Best Practices for vSphere 7.0 Update 3, Revision 20220228b, nennen den Beginn des TCP-Transports: „ab ESXi 7.0 Update 3“.

NVMe over TCP vs iSCSI in vSphere

Beide Protokolle laufen über Ethernet und TCP und unterscheiden sich im Speicher-Stack darüber. Broadcoms KB 433394 erklärt, dass NVMe over TCP „den nativen NVMe-Stack nutzt“ statt der SCSI-Schicht, Geräte über EUI oder NGUID statt über NAA identifiziert und sich über Subsysteme, Controller und Namespaces verbindet statt über Target-IQNs und Sitzungen. Broadcoms Seite zu den Anforderungen stellt SCSI-over-Fabric-Speicher, zu dem iSCSI gehört, dem NVMe-over-Fabric-Speicher gegenüber.

Broadcom TechDocs, vSphere Storage, Requirements for VMware NVMe Storage, Versionen 8.0 (16. September 2026), 9.0 (24. August 2026) und 9.1 (12. Oktober 2026); Broadcom KB 433394 und KB 401070; vVols über NVMe/TCP laut VMware, What’s New with vSphere 8 Core Storage.

Zur Leistung schreiben VMwares Performance Best Practices for vSphere 7.0 Update 3, dass „NVMe-oF höhere IOPS und niedrigere Latenzen bietet als viele andere Optionen für entfernten Speicher“, „mit potenziell geringeren CPU-Kosten je I/O“. Ein Broadcom-Dokument mit einem allgemeinen Wert für IOPS, Latenz oder CPU von NVMe over TCP gegenüber iSCSI haben wir nicht gefunden. Der Gewinn hängt vom Array, seiner Firmware und dem Netzwerk ab; vergleichen Sie also zuerst beide Protokolle auf demselben Array mit Ihrer eigenen Last.

Anforderungen und wo Sie sie prüfen

KB 430071 legt die Regel für NVMe-Speicher in vSphere fest: „NVMe-Hardware muss mit der installierten vSphere-Version kompatibel bzw. dafür zertifiziert sein“, und dasselbe gilt für Treiber und Firmware. In vSphere bedeutet das den Broadcom Compatibility Guide (BCG), für das Array mit NVMe over TCP und für den Netzwerkadapter jedes Hosts.

Broadcom KB 430071, KB 392397, KB 401070; vSphere Storage 8.0 und 9.0 (Juli bis September 2026); Release Notes zu VCF 9.0, What’s New in vSphere (29. September 2026); VMware, What’s New with vSphere 8 Core Storage.

KB 392397 für ESXi 8.x beschreibt häufige Pfadverluste und Leistungseinbußen auf NVMe-over-TCP-Datastores, „wenn die Funktion Data Digest aktiviert ist“. Als Workaround wird Data Digest deaktiviert, denn Header Digest „ist von diesem Problem nicht betroffen und kann aktiviert bleiben“, und der Artikel kündigt eine Korrektur in einem künftigen nvmetcp-Treiber für ESXi 8.x und ESX 9.x an. Laut KB löst die Standardeinstellung, bei der beide Digests deaktiviert sind, das Problem nicht aus; lassen Sie Data Digest auf Hosts mit 8.x also ausgeschaltet.

Wo mit dem Protokollwechsel neue Hosts kommen, behandelt unser Leitfaden zum Austausch von ESXi-Hosts EVC und die Überschneidung der Lizenzen, und unser Überblick über VCF 9.1, was sich in 9.1 sonst geändert hat.

Netzwerkdesign für NVMe/TCP

Die VMkernel-Bindung in Broadcoms Handbuch zu 8.0, aktualisiert am 2. September 2026, nutzt eine „1:1-Zuordnung zwischen jedem virtuellen und physischen Netzwerkadapter“ und schreibt, für diese VMkernel-Adapter weder „LACP oder andere nicht unterstützte Konfigurationen“ einzurichten noch Port-Channel oder EtherChannel auf den physischen Switches. Dieselbe Seite hält fest, dass NVMe over TCP „sich auf VMware Storage Multipathing stützt, um Hochverfügbarkeit, Failover und Lastverteilung bereitzustellen“. Das Verfahren für den Distributed Switch in der Fassung 7.0 des Handbuchs setzt je Portgruppe einen Uplink als aktiv und den anderen als unused. Redundanz entsteht also durch zwei Software-Adapter auf zwei vmnics, deren Pfade HPP verwaltet, wie in Broadcoms Beispieltopologie mit zwei Standard-Switches, zwei vmnics und zwei externen Switches.

VMwares Konfigurationspapier zu NVMe/TCP empfiehlt Port Binding und verlangt einen VMkernel-Adapter für jedes genutzte Subnetz. Dedizierte NICs für NVMe/TCP nennt es eine bewährte Praxis, die „aber nicht erforderlich ist“, und rät davon ab, den Verkehr zu routen, weil „jeder Hop Latenz hinzufügen kann“. Der Performance-Leitfaden zu 7.0 Update 3 empfiehlt Jumbo Frames auf den Netzwerkverbindungen und mindestens eine verteilte Portgruppe je vmnic, und das Verfahren für den Distributed Switch verlangt, dass die MTU des VMkernel-Adapters der MTU des Switches entspricht. Eine erhöhte MTU muss durchgängig übereinstimmen, von den VMkernel-Adaptern bis zu den Ports des Arrays.

Broadcoms Anforderungen nennen einen Ethernet-Adapter und keine Mindestgeschwindigkeit. Nach unserer Lesart plant ein Cluster mit 10 bis 60 Hosts zwei dedizierte 25-GbE-Ports je Host für den Speicher, einen je Fabric und VLAN, oder 100 GbE, wo die Ports des Arrays und die Last es verlangen. Nehmen Sie einen Cluster mit 16 Hosts und 40 Datastores, in dem jeder der beiden Adapter zwei Array-Ports erreicht. Jeder Namespace hat dann 4 Pfade und jeder Host 160 Pfade, deutlich innerhalb der 32 Pfade je Namespace, die VMwares Core-Storage-Papier ab vSphere 8.0 Update 1 nennt, und seiner Angabe für vSphere 8 von „256 Namespaces und 2K Pfaden“. Prüfen Sie beide Werte für Ihr Release in Broadcoms Configuration Maximums, bevor Sie dimensionieren. Wie ein solcher Cluster zum Rest der Umgebung passt, steht in unserem Leitfaden zum Design von vSphere-Clustern.

NVMe over TCP auf ESX einrichten

Broadcoms Handbücher zu 8.0 und 9.0 geben die Reihenfolge vor: einen unterstützten Adapter installieren, die VMkernel-Bindung konfigurieren, den Software-Adapter für NVMe over TCP hinzufügen und Controller hinzufügen. Zusammen mit der Array-Seite sieht das Verfahren je Host so aus.

1. Erstellen Sie je Fabric einen Standard- oder Distributed Switch mit einer vmnic als einzigem aktivem Uplink und setzen Sie die VLAN-ID des Speichernetzes.
2. Fügen Sie auf jeder Portgruppe einen VMkernel-Adapter mit seinen IP-Einstellungen hinzu und aktivieren Sie darauf den Dienst NVMe over TCP.
3. Klicken Sie unter Configure, Storage Adapters auf das Symbol Add Software Adapter, wählen Sie NVMe over TCP adapter und die vmnic; wiederholen Sie das für die zweite vmnic. Jeder Adapter erscheint als vmhba.
4. Registrieren Sie die Host-NQN auf dem Array als neues NVMe-Host-Objekt; VMwares Papier schreibt, die NQN „ist für den Host eindeutig, nicht für die Adapter“, und warnt davor, iSCSI-Hostgruppen wiederzuverwenden.
5. Öffnen Sie auf jedem vmhba den Tab Controllers und fügen Sie einen Controller hinzu, automatisch mit IP-Adresse, Transportport und Digest-Einstellungen oder manuell mit der Subsystem-NQN. Die Größe der Admin-Queue ist standardmäßig 16 und das Keep-Alive-Timeout 60 Sekunden.
6. Ordnen Sie die Namespaces auf dem Array den Hosts zu; VMwares Papier merkt an: „Für NVMe ist kein Storage Rescan erforderlich.“
7. Erstellen Sie von einem Host aus einen VMFS-Datastore auf einem Namespace und prüfen Sie, dass jeder Host im Cluster ihn sieht.

Zur Prüfung kontrollieren Sie im Tab Controllers, dass jeder Controller online ist, und führen auf dem Host esxcli nvme adapter list und esxcli nvme controller list aus, wie KB 433394 beschreibt. Der Artikel erklärt außerdem, dass die Ansicht Paths im vSphere Client nicht für jeden Pfad eines NVMe-over-TCP-Geräts das Ziel zeigt, und nennt dies erwartetes Verhalten. Sieht ein Host keine Ziele, während andere sie sehen, verweist KB 449699 auf eine vmnic, die im Teaming der NVMe-Portgruppe auf unused gesetzt ist. Der Adapter ist dann in esxcli storage core adapter list online, ohne Geräte oder Pfade dahinter.

Unsere VMware-Optimierung umfasst Versions- und Architektur-Updates von vSphere, in vereinbarten Wartungsfenstern mit Rollback-Plan. Nennen Sie uns Ihr Array, Ihre ESX-Versionen und Ihr Speichernetz und welche Datastores Sie zuerst umziehen würden.

Grenzen und nicht unterstützte Funktionen

Raw Device Mappings funktionieren auf NVMe-oF nicht; eine VM mit einem RDM auf iSCSI behält diese Platte also auf iSCSI, oder die Platte wird zuvor in ein VMDK umgewandelt. SCSI-2-Reservierungen werden nicht unterstützt, was für ältere Gastcluster zählt, die sich darauf stützen. Die Handbücher führen auch Core Dump auf NVMe-oF als nicht unterstützt auf; behalten Sie das Core-Dump-Ziel der Hosts also auf lokalem oder SCSI-Speicher. Clustered VMDK und Shared VMDK mit dem Multi-Writer-Flag werden unterstützt, und VMwares Core-Storage-Papier schreibt, dass vSphere 8.0 Update 3 die Unterstützung für Gastcluster auf NVMe/TCP ausgeweitet hat, nachdem sie auf NVMe/FC beschränkt war.

Hardwarebeschleunigung mit VAAI-Plug-ins wird auf NVMe-oF nicht unterstützt. Dasselbe Core-Storage-Papier führt NVMe-oF Cross Namespace Copy in vSphere 8.0 Update 3 auf, das „die Datenübertragung an das Array auslagert“; prüfen Sie also, ob die Firmware Ihres Arrays es unterstützt. Unter 8.x geben vVols über NVMe jedem virtuellen Volume einen eigenen Namespace, und Broadcoms Handbuch zu 8.0 schreibt: „Die Namespace-Grenzen hängen vom Array-Hersteller ab.“

Broadcoms Handbuch schreibt außerdem: „Mischen Sie keine Transporttypen für den Zugriff auf denselben Namespace.“ Für iSCSI ergänzt VMwares Konfigurationspapier, man solle nicht „eine NVMe-NQN zu einem SCSI-Target hinzufügen“, und warnt, dass eine Vermischung zu Datenbeschädigung führen kann.

iSCSI-Datastores auf NVMe over TCP migrieren

Da ein Volume nicht zugleich über iSCSI und NVMe over TCP bereitgestellt wird, baut die Migration neue NVMe-Namespaces neben den iSCSI-LUNs auf und verschiebt die VMs im laufenden Betrieb mit Storage vMotion. Broadcoms Grenzen für gleichzeitige Migrationen unter vSphere 8.0, aktualisiert am 16. September 2026, erlauben 2 Storage-vMotion-Vorgänge je Host und rechnen jedem auf dem Datastore Kosten von 16 bei einem Maximum von 128 an, also 8 gleichzeitig je Datastore.

Verschieben Sie RDMs und VMs, die von SCSI-2-Reservierungen abhängen, zuletzt, oder lassen Sie sie auf iSCSI. Sobald ein Datastore leer ist, hängen Sie ihn aus, trennen das Gerät auf jedem Host und entfernen die LUN auf dem Array, bevor Sie ihre Kapazität wiederverwenden. Ist der letzte iSCSI-Datastore eines Clusters entfernt, entfernen Sie auch den Software-iSCSI-Adapter und seine VMkernel-Bindung.

Im Rahmen unserer VMware-Optimierung laufen solche Änderungen in vereinbarten Wartungsfenstern, Schritt für Schritt, mit Rollback-Plan in jeder Etappe. Beschreiben Sie Ihre iSCSI-Datastores im Formular unten, mit ihrer Zahl, ihren Größen und den VMs, die RDMs nutzen.

Wann NVMe over TCP iSCSI überlegen ist und wann iSCSI bleibt

NVMe over TCP passt besser, wenn das Array für NVMe over TCP mit Ihrem ESX-Release gelistet ist, die Hosts 8.x oder 9.x betreiben und die Workloads VMFS-Datastores ohne RDMs nutzen. Es läuft über das Ethernet-Netz, das Sie bereits betreiben. iSCSI bleibt die Wahl für RDMs, für Gastcluster, die SCSI-2-Reservierungen brauchen, für Abläufe, die von VAAI abhängen, und für Arrays oder NICs, die für NVMe over TCP nicht gelistet sind.

Wo die Hosts lokale NVMe-Geräte tragen und das Array zum Austausch ansteht, ist vSAN die andere Option für den Vergleich; unser Vergleich von vSAN ESA und OSA behandelt Hardware und Lizenzierung in 9.x.

Was wir tun

Der Wechsel von iSCSI zu NVMe over TCP ist ein Versions- und Architektur-Update im Sinn unserer VMware-Optimierung. Unser Engineering-Partner Vixen.UNO beginnt mit einer vollständigen Inventur Ihrer VMware-Umgebung mit Versionen, tatsächlicher Ressourcennutzung und Risikoprofil und führt dann die Updates von vSphere, vSAN, NSX und VCF durch, clusterübergreifende Migrationen eingeschlossen. Eurokommerz hält den Vertrag und liefert die Hardware zur Lösung, etwa Netzwerkkarten und Switches für das Speichernetz, mit EU-Rechnungsstellung, Lieferung und Garantie nach europäischem Recht. Änderungen laufen in vereinbarten Wartungsfenstern, Schritt für Schritt, mit Rollback-Plan in jeder Etappe, danach folgt Support unter einem vereinbarten SLA. Das erste Gespräch ist kostenlos, und der Preis des technischen Assessments steht vor Beginn fest.

FAQ