NVMe over Fabrics carries NVMe commands across a network; iSCSI carries SCSI commands over TCP. That is the central distinction in NVMe-oF vs iSCSI. Fibre Channel is a fabric that can carry SCSI through FCP or NVMe through FC-NVMe, so the three labels do not describe mutually exclusive networks.
For a homelab or small-business SAN, start by checking what the host operating system and storage array support together. Then choose the fabric, path layout and recovery behaviour. A protocol name alone cannot establish application latency or prove that an existing NIC, HBA or array supports the proposed configuration. If the block-storage model itself is new, start with what is a SAN storage area network.
This guide compares those design choices. For the access controls behind them, read SAN zoning and LUN masking explained.
NVMe-oF vs iSCSI: what changes
NVMe-oF extends the NVMe command and queue model beyond a local PCIe connection. NVM Express documents the architecture in its specifications, with separate transport specifications for TCP and RDMA. The older standalone NVMe-oF specification is now a historical reference; its architecture was incorporated into the NVMe Base specification.
iSCSI uses the SCSI command model defined for remote block access in RFC 7143. A host addresses logical units through an iSCSI target. NVMe uses controllers and namespaces, with NVMe Qualified Names identifying hosts and subsystems. These differences affect discovery, access configuration and host software; changing the transport is more than changing an IP address.
The practical question is whether a supported NVMe path helps the workload that the existing storage stack must serve. Keep the comparison tied to its read/write mix, I/O size, concurrency and latency objective. There is no standards-defined percentage by which every NVMe-oF deployment beats every iSCSI deployment.
SAN transports at a glance
| Design question | NVMe over Fabrics | iSCSI | Fibre Channel with FCP |
|---|---|---|---|
| Command model | NVMe | SCSI | SCSI |
| Transport choice | TCP, RDMA or Fibre Channel | TCP/IP | Fibre Channel |
| Storage presented to the host | Namespaces | Logical units (LUNs) | Logical units (LUNs) |
| Endpoint identity | NQNs plus transport addresses | iSCSI names plus IP portals | WWNs |
| Fabric planning | Depends on the chosen binding | IP reachability, congestion and independent paths | Zoning, credits and independent fabrics |
| Compatibility to confirm | Host NVMe stack, transport and subsystem | Initiator, target and multipath support | HBA, switches, array and host profile |
FC-NVMe belongs in the first column even though it uses the fabric in the third. Compare FCP against FC-NVMe when evaluating command protocols on an existing FC network; compare NVMe/TCP against iSCSI when evaluating TCP-based block storage.
Choose the NVMe-oF fabric before sizing ports
NVMe/TCP maps NVMe communication onto TCP/IP. The NVM Express TCP transport specification defines that mapping. It does not make an iSCSI target into an NVMe subsystem, and an Ethernet connection alone does not establish end-to-end support. Check the host and array support matrices before treating existing network equipment as a complete solution.
FC-NVMe carries NVMe over Fibre Channel. It can preserve the zoning and fabric-management concepts of an FC deployment, but hardware, firmware and host support still need verification. An existing FC installation is a reason to evaluate FC-NVMe, not proof that every component can carry it.
NVMe over RDMA uses a remote-memory transport. RDMA implementations include RoCE, iWARP and InfiniBand; they do not all have identical network requirements. Confirm the selected transport’s adapter, switch and congestion-control requirements against the supported deployment guide. Avoid applying a RoCE configuration recipe to every RDMA network.
For an Ethernet-based first evaluation, compare the supported NVMe/TCP configuration with the supported iSCSI configuration. Keep RDMA or FC-NVMe in consideration when the available equipment and operational requirements justify them.
NVMe/TCP vs iSCSI within the wider comparison
Both use TCP, but they carry different storage commands and require different host and target stacks. Reusing an IP network does not reuse an iSCSI session, its authentication settings or its LUN mapping.
Keep this initial comparison to three checks: whether both ends support the protocol, how storage access is restricted, and how the host recovers after a path disappears. Record the exact host version, array firmware and supported multipath configuration for each candidate. Those details provide a useful basis for a later deployment decision without assuming a speed gain.
For target, initiator, CHAP and LUN configuration, see What is an iSCSI LUN? Targets, initiators and MPIO on iSCSI Hub. That guide owns the iSCSI setup steps; the fabric choices remain the focus here.
Fibre Channel: zoning and congestion still matter
Fibre Channel provides a storage fabric with its own addressing and credit-based flow control. Whether it carries FCP or FC-NVMe, the design still needs an explicit map of host ports, target ports and permitted communication.
Plan two independent routes when continued access after a single path failure is a requirement. Document shared switches, inter-switch links and controllers rather than counting cables alone. The zoning and masking guide explains why fabric access and volume access are separate controls.
Credit-based flow control does not remove congestion. When investigating delayed I/O, use the SAN high latency triage guide to separate host queues, fabric symptoms and array activity before changing the transport.
Compare latency using the same workload
Write down the acceptance criteria before evaluating alternatives. Include application latency percentiles, required throughput, concurrent operations and what should happen during a supported failover exercise. Use the same workload and comparable storage layout for each candidate.
Keep normal operation and degraded operation as separate results. A configuration that meets the throughput requirement with every path available may need more capacity when one path is unavailable. Conversely, adding ports does not establish that the application can use them concurrently.
The SAN LUN Capacity Calculator supplies a first estimate of RAID-adjusted space and aggregate FC bandwidth. Its fixed capacity ratios and bandwidth assumptions are planning aids. Use the array’s supported capacity calculation and workload evidence before committing a design.
A decision order for a small SAN
- List supported combinations. Record the host, adapter, switch, array and firmware requirements for each transport under consideration.
- Draw storage ownership. Identify which host or coordinated cluster may write to each LUN or namespace.
- Draw independent paths. Identify the components shared by all routes, including power and switching.
- Set a workload objective. Define the latency, throughput and recovery requirements that would justify changing the current design.
- Estimate capacity and bandwidth. Allow for array reserves and the path capacity available during maintenance.
- Plan the transition. Follow the array and operating-system migration procedures rather than assuming the same data can be exposed safely through two protocols at once.
An existing supported iSCSI deployment can remain a sensible choice when it meets those requirements. A supported NVMe-oF deployment becomes a candidate when its command model, fabric options and host support fit the intended workload. Neither decision removes the need for access controls, backups or documented recovery.
