iSCSI vs. NVMe/TCP: The ultimate storage showdown for Red Hat OpenShift Virtualization | Red Hat Developer

Skip to main content

Search

Search

All Red Hat

iSCSI vs. NVMe/TCP: The ultimate storage showdown for Red Hat OpenShift Virtualization

Performance comparison: iSCSI vs. NVMe/TCP in Red Hat OpenShift Virtualization

June 4, 2026

Sonali Badal

Related topics:<br>Virtualization

Related products:<br>Red Hat OpenShift Virtualization

Table of contents:

As virtualization density continues to grow in modern data centers, selecting the right storage protocol has become increasingly important, and directly impacts CPU efficiency, I/O overhead, and overall application responsiveness. In this article, we take a closer look at how two IP-based storage protocols—iSCSI and NVMe/TCP—compare within a Red Hat OpenShift Virtualization environment to help you determine whether a transition makes sense for your infrastructure.<br>For many years, the go-to solution for accessing block-level storage over standard ethernet networks has been iSCSI. It established itself as a dependable, widely adopted standard by packaging SCSI commands into TCP/IP packets. In the age of spinning disks, iSCSI delivered more than adequate performance. However, its single-queue architecture can become a limiting factor when paired with a modern SSD (solid-state drive).<br>NVMe/TCP, on the other hand, represents a newer approach built specifically for high-performance flash storage. It extends the NVMe protocol—designed with parallelism and efficiency in mind—across standard TCP/IP networks. The fundamental distinction is straightforward: iSCSI adapts a legacy, sequential protocol (SCSI) to modern networking, whereas NVMe/TCP leverages a natively parallel protocol (NVMe) on the same fast infrastructure. This architectural shift enables lower latency and higher IOPS in practice.<br>Tests in this article are based on a 7-node Dell server cluster connected to a Dell PowerStore all-flash array, allowing us to measure tangible performance differences.<br>The hardware and software behind the numbers<br>To evaluate iSCSI and NVMe/TCP under realistic conditions, we built a controlled environment using a fully Dell-based infrastructure. All compute, networking, and storage components were kept identical across tests to ensure that the storage protocol was the only variable influencing performance.<br>Platform:<br>Red Hat OpenShift Container Platform: v4.19.1<br>Red Hat OpenShift Virtualization: v4.19.3<br>Compute: The cluster was deployed on 7 Dell PowerEdge R760 servers , split across:<br>3 Control Plane (Master) nodes<br>3 Worker nodes<br>1 Bastion node<br>Each server was identically configured to eliminate hardware-induced variability:<br>CPU: 128 x Intel Xeon Gold 6430 processors (64 threads/socket)<br>Memory: 512 GB RAM<br>Network interfaces: 2 &times; Mellanox ConnectX-6 Dx 100GbE adapters. These network cards were used for both iSCSI and NVMe/TCP storage traffic on the worker nodes.<br>OpenShift used 25 GbE network interfaces for pod networking.

Operating system (Bastion node) : Red Hat Enterprise Linux 9.4This OS detail applies only to the bastion node.

Storage<br>At the heart of our SAN was a Dell PowerStore 9200 all-flash array. This platform was chosen specifically for its native support for both iSCSI and NVMe/TCP, allowing us to perform a true like-to-like comparison by simply changing the host-side protocol. Six ports were used at the storage side, and the port speed for both the protocols was fixed at 25 Gb/s.<br>Provisioning<br>We provisioned two separate sets of storage from the Dell array: 3x 1 TB LUNs for iSCSI and another 3x 1 TB LUNs for NVMe/TCP. Each worker node was assigned two 1 TB volumes—one exposed over iSCSI and the other over NVMe/TCP—allowing a direct, side-by-side comparison of both protocols. The LVM operator in OpenShift was used to configure and manage storage in both cases, with dedicated storage classes created for each protocol.<br>To enable a side-by-side comparison, separate storage classes were defined: lvms-iscsi for iSCSI and lvms-nvme for NVMe/TCP. While iSCSI leveraged traditional multipathing with asymmetric logical unit access (ALUA), NVMe/TCP volumes were accessed over multiple paths using a round-robin I/O policy with asymmetric namespace access (ANA).<br>Network<br>All traffic ran over high-speed, low-latency IP fabric switches. The network was configured for storage best practices, including end-to-end 25GbE and jumbo frames (MTU 9000) enabled.<br>With this hardware in place, we established a clean, reproducible environment to accurately evaluate the performance and efficiency differences between the two protocols. Beyond the configurations already described, a few additional performance tuning adjustments were applied, which are discussed later. Figure 1 displays an architectural overview of our setup.

Figure 1: An architectural overview of the hardware used for storage tests.

Test results and methodology<br>Benchmarks were structured to evaluate protocol performance...