NVMe over TCP in vSphere: requirements, setup on ESX and when it beats iSCSI

What NVMe over TCP in vSphere needs

vSphere supports NVMe over TCP (NVMe/TCP) from ESXi 7.0 Update 3, and ESXi 8.x and ESX 9.x keep it as one of three shared NVMe over Fabrics (NVMe-oF) transports, beside Fibre Channel and RDMA (RoCE v2). Broadcom’s vSphere Storage guide for 9.0, updated on 24 August 2026, and its 9.1 version, updated on 12 October 2026, list what a host needs: an NVMe storage array with NVMe over TCP transport support, a compatible ESX host, an Ethernet adapter, a software NVMe over TCP adapter and an NVMe controller, which “you must add” after the software adapter is configured. Broadcom calls the hypervisor ESX from version 9.0 and ESXi up to 8.x.

The software adapter is bound to a VMkernel adapter tagged with the NVMe over TCP service. Namespaces on the array appear as storage devices and are formatted as VMFS datastores. The guide also lists vVols over NVMe-oF from vSphere 8.0, but Broadcom’s KB 401070 deprecates vVols from VCF and VVF 9.0 and discontinues all vVol certifications for 9.0, so plan NVMe over TCP storage on 9.x as VMFS. The High-Performance Plug-in (HPP) handles multipathing, and the native multipathing plug-in (NMP) used for iSCSI cannot claim NVMe-oF targets. VMware’s Performance Best Practices for vSphere 7.0 Update 3, revision 20220228b, give the start of the TCP transport, “starting with ESXi 7.0 Update 3”.

NVMe over TCP vs iSCSI in vSphere

Both protocols run over Ethernet and TCP and differ in the storage stack above it. Broadcom’s KB 433394 explains that NVMe over TCP “uses the native NVMe stack” rather than the SCSI layer, identifies devices by EUI or NGUID instead of NAA, and connects through subsystems, controllers and namespaces instead of target IQNs and sessions. Broadcom’s requirements page sets SCSI over fabric storage, which includes iSCSI, against NVMe over fabric storage.

Broadcom TechDocs, vSphere Storage, Requirements for VMware NVMe Storage, versions 8.0 (16 September 2026), 9.0 (24 August 2026) and 9.1 (12 October 2026); Broadcom KB 433394 and KB 401070; vVols over NVMe/TCP from VMware, What’s New with vSphere 8 Core Storage.

On performance, VMware’s Performance Best Practices for vSphere 7.0 Update 3 state that “NVMe-oF offers higher IOPS and lower latencies than many other remote storage options”, “with potentially lower CPU cost per I/O”. We found no Broadcom document that gives a general IOPS, latency or CPU figure for NVMe over TCP against iSCSI. The gain depends on the array, its firmware and the network, so compare both protocols on the same array with your own workload first.

Requirements and where to check them

KB 430071 sets the rule for NVMe storage in vSphere: “NVMe HW needs to be compatible/certified with installed vSphere Version”, and the driver and firmware must be as well. In vSphere that means the Broadcom Compatibility Guide (BCG), for the array with NVMe over TCP and for the network adapter of every host.

Broadcom KB 430071, KB 392397, KB 401070; vSphere Storage 8.0 and 9.0 (July to September 2026); VCF 9.0 release notes, What’s New in vSphere (29 September 2026); VMware, What’s New with vSphere 8 Core Storage.

KB 392397, for ESXi 8.x, describes frequent path loss and performance degradation on NVMe over TCP datastores “when data digest feature is enabled”. Its workaround is to disable data digest, since header digest “is not affected by this issue and can be left enabled”, and it says a fix will come in a future nvmetcp driver for ESXi 8.x and ESX 9.x. The KB says the default, with both digests disabled, does not trigger the issue, so leave data digest off on 8.x hosts.

Where new hosts come with the change of protocol, our guide to a VMware host refresh covers EVC and the licence overlap, and our overview of VCF 9.1 what else changed in 9.1.

Network design for NVMe/TCP

The VMkernel binding in Broadcom’s 8.0 guide, updated on 2 September 2026, uses “1:1 mapping between each virtual and physical network adapter” and says not to configure “LACP or other unsupported configurations” for these VMkernel adapters, nor port-channel or EtherChannel on the physical switches. The same page states that NVMe over TCP “relies on VMware Storage Multipathing to provide high availability, failover, and load balancing”. The distributed switch procedure in the 7.0 version of the guide assigns one uplink as active for each port group and the other as unused. Redundancy therefore comes from two software adapters on two vmnics, with HPP managing the paths, as in Broadcom’s example topology with two standard switches, two vmnics and two external switches.

VMware’s configuration paper for NVMe/TCP recommends port binding and asks for a VMkernel adapter for each subnet in use. It calls dedicated NICs for NVMe/TCP a best practice “but is not required”, and advises against routing the traffic, because “each hop can add latency”. The 7.0 Update 3 performance guide recommends jumbo frames on the network links and at least one distributed port group per vmnic, and the distributed switch procedure asks for the VMkernel MTU to match the switch MTU. A raised MTU has to match end to end, from the VMkernel adapters to the array ports.

Broadcom’s requirements name an Ethernet adapter and no minimum speed. By our reading, a cluster of 10 to 60 hosts plans two dedicated 25 GbE ports per host for storage, one per fabric and VLAN, or 100 GbE where the array ports and the workload call for it. Take a 16-host cluster with 40 datastores, where each of the two adapters reaches two array ports. Each namespace then has 4 paths and each host 160 paths, well inside the 32 paths per namespace that VMware’s core storage paper gives from vSphere 8.0 Update 1 and its vSphere 8 figure of “256 namespaces and 2K paths”. Confirm both figures for your release in Broadcom’s Configuration Maximums before you size. How such a cluster fits the rest of the estate is in our vSphere cluster design guide.

How to set up NVMe over TCP on ESX

Broadcom’s 8.0 and 9.0 guides give the order: install a supported adapter, configure VMkernel binding, add the software NVMe over TCP adapter and add controllers. With the array side added, the procedure per host is as follows.

1. Create a standard or distributed switch per fabric with one vmnic as its only active uplink, and set the VLAN ID of the storage network.
2. Add a VMkernel adapter on each port group, with its IP settings, and enable the NVMe over TCP service on it.
3. Under Configure, Storage Adapters, click the Add Software Adapter icon, select NVMe over TCP adapter and pick the vmnic; repeat for the second vmnic. Each adapter appears as a vmhba.
4. Register the host NQN on the array as a new NVMe host object; VMware’s paper says the NQN “is unique to the host, not the adapters” and warns not to reuse iSCSI host groups.
5. On each vmhba, open Controllers and add a controller, automatically with the IP address, transport port and digest settings, or manually with the subsystem NQN. The admin queue size defaults to 16 and the keep alive timeout to 60 seconds.
6. Map the namespaces to the hosts on the array; VMware’s paper notes that “No storage rescan is required for NVMe.”
7. Create a VMFS datastore on a namespace from one host and confirm that every host in the cluster sees it.

To verify, check that each controller is online in the Controllers tab, and run esxcli nvme adapter list and esxcli nvme controller list on the host, as KB 433394 describes. The KB also explains that the Paths view in the vSphere Client does not show the target for every path of an NVMe over TCP device, and calls this expected behaviour. If a host sees no targets while others do, KB 449699 points to a vmnic set to unused in the teaming of the NVMe port group. The adapter is then online in esxcli storage core adapter list, with no devices or paths behind it.

Our VMware optimisation service covers version and architecture updates of vSphere, in agreed maintenance windows with a rollback plan. Tell us your array, ESX versions and storage network, and which datastores you would move first.

Limits and unsupported features

Raw device mappings do not work on NVMe-oF, so a VM with an RDM on iSCSI keeps that disk on iSCSI or has it converted to a VMDK first. SCSI-2 reservations are not supported, which matters for older guest clusters that rely on them. The guides also list core dump as not supported on NVMe-oF, so keep the hosts’ core dump target on local or SCSI storage. Clustered VMDK and shared VMDK with the multi-writer flag are supported, and VMware’s core storage paper says vSphere 8.0 Update 3 extended guest clustering support to NVMe/TCP, where it had been limited to NVMe/FC.

Hardware acceleration with VAAI plug-ins is not supported on NVMe-oF. The same core storage paper lists NVMe-oF Cross Namespace Copy in vSphere 8.0 Update 3, which “offloads the data transfer to the array”, so check whether your array firmware supports it. On 8.x, vVols over NVMe give each virtual volume its own namespace, and Broadcom’s 8.0 guide says “The namespace limits depend on the array vendor.”

Broadcom’s guide also says “Do not mix transport types to access the same namespace.” For iSCSI, VMware’s configuration paper adds not to “add an NVMe NQN to a SCSI target” and warns that mixing could result in data corruption.

Migrating iSCSI datastores to NVMe over TCP

Because a volume is not presented over iSCSI and NVMe over TCP at once, the migration builds new NVMe namespaces beside the iSCSI LUNs and moves the VMs with Storage vMotion while they run. Broadcom’s limits on simultaneous migrations for vSphere 8.0, updated on 16 September 2026, allow 2 Storage vMotion operations per host and give each a datastore cost of 16 against a maximum of 128, so 8 at a time per datastore.

Move RDMs and VMs that depend on SCSI-2 reservations last, or leave them on iSCSI. Once a datastore is empty, unmount it, detach the device on every host and remove the LUN on the array before you reuse its capacity. When the last iSCSI datastore of a cluster is gone, remove the software iSCSI adapter and its VMkernel binding.

Under our VMware optimisation service, changes like this run in agreed maintenance windows, step by step, with a rollback plan at every stage. Describe your iSCSI datastores in the form below, with their number, sizes and the VMs that use RDMs.

When NVMe over TCP beats iSCSI and when to keep iSCSI

NVMe over TCP is the better fit when the array is listed for NVMe over TCP with your ESX release, the hosts run 8.x or 9.x and the workloads use VMFS datastores without RDMs. It runs on the Ethernet network you already operate. iSCSI stays the choice for RDMs, guest clusters that need SCSI-2 reservations, workflows that depend on VAAI and arrays or NICs not listed for NVMe over TCP.

Where the hosts carry local NVMe devices and the array is due for replacement, vSAN is the other option to compare, and our comparison of vSAN ESA and OSA covers its hardware and licensing in 9.x.

What we do

A move from iSCSI to NVMe over TCP is a version and architecture update in the sense of our VMware optimisation service. Our engineering partner Vixen.UNO starts with a full inventory of your VMware estate, with versions, actual resource usage and risk profile, and then carries out the updates of vSphere, vSAN, NSX and VCF, cross-cluster migrations included. Eurokommerz holds the contract and supplies the hardware under the solution, such as NICs and switches for the storage network, with EU invoicing, delivery and warranty under European law. Changes run in agreed maintenance windows, step by step, with a rollback plan at every stage, followed by support under an agreed SLA. The first call is free of charge, and the price of the technical assessment is fixed before work begins.

FAQ