Mature shared block storage across familiar IP networks
iSCSI carries the established SCSI command model over TCP/IP. It remains a strong choice for virtualisation, databases and mixed operating-system environments when compatibility, mature tooling and predictable operations matter as much as protocol efficiency.
Independent session
Independent session
Active/Optimised
Available path
The host receives a block device—not a shared directory
The storage system presents logical units through an iSCSI target. The initiator discovers the target, authenticates where required and establishes one or more sessions to the target portals.
Initiator
The host-side software or adapter that discovers targets and sends SCSI commands over the IP network.
Target and IQN
The storage endpoint has a persistent iSCSI Qualified Name that is independent of any single network address.
Portal and session
An IP address and TCP port provide network access. Multiple portals and sessions can create independent paths.
LUN
The logical unit appears to the host as a disk. The host or cluster owns the file system and application data structure.
One LUN must not be mounted read/write by unrelated hosts without coordination. Shared block access requires a cluster-aware file system or an application such as VMware VMFS that manages concurrent ownership correctly.
iSCSI remains relevant because compatibility is an architectural advantage
The newest command model is not automatically the correct choice for every host, workload or operating team.
| Protocol | Command model | Network | Operational profile | Typical fit |
|---|---|---|---|---|
| iSCSI | SCSI over TCP | Routable Ethernet / IP | Mature initiators, diagnostics and broad compatibility | Mixed hosts and established IP SANs |
| iSER | iSCSI with RDMA data transfer | Qualified RoCE or InfiniBand path | iSCSI ecosystem with RDMA fabric requirements | Lower-overhead iSCSI where support is validated |
| NVMe/TCP | Native NVMe over TCP | Routable Ethernet / IP | Modern parallel command model and current host support | New shared block deployments |
| Fibre Channel | SCSI over dedicated FC fabric | Specialised SAN network | Deterministic and operationally separate | Existing enterprise FC environments |
Standard Ethernet does not remove the need for storage discipline
iSCSI is straightforward to route and monitor, but production storage traffic still needs deliberate path separation, consistent MTU, correct host binding and a defined security model.
For VMware software iSCSI, port binding is appropriate only for specific same-subnet designs and requires one VMkernel port per physical uplink. Broadcom explicitly advises against using LACP as a substitute for software iSCSI multipathing.
Multiple sessions should become one correctly prioritised device
Host MPIO prevents each path from appearing as an unrelated disk. ALUA then tells the initiator which target-port group is active/optimised for a particular LUN and which paths remain active/non-optimised or available for recovery.
eEKAS example: a distributed IP Group with at least two addresses and two eligible gateway nodes enables ALUA multipathing. Additional LUNs are assigned to gateway addresses in round-robin order while the other paths remain available for failover.
iSCSI is useful wherever a reliable remote disk is more important than a shared file namespace
VMFS datastores
Broad host support, mature software initiators and established path policies make iSCSI a practical datastore transport.
Hyper-V clusters
Windows Server includes an iSCSI initiator; clustered deployments should enable and validate MPIO on every host.
eEVOS
The integrated initiator can consume compatible shared iSCSI storage while eEVOS provides virtualisation, Backup & Disaster Recovery and storage functions.
Databases
Dedicated LUNs provide familiar block semantics, but queue depth, write durability and failover behaviour require application-level testing.
Mixed host estates
Native initiators and mature diagnostics make iSCSI useful when several operating-system families must use the same storage platform.
Boot and appliance volumes
Selected platforms can boot from iSCSI or use it for dedicated appliance disks where persistent discovery and recovery are validated.
VMware, Hyper-V and eEVOS use the same LUN differently
Protocol compatibility is only the first layer. Each virtualisation platform has its own path management, cluster coordination and operational model.
VMware vSphere
Use the supported software or hardware iSCSI adapter design, configure target discovery and validate the SATP/PSP behaviour. With ALUA, Round Robin normally uses active/optimised paths.
Microsoft Hyper-V
Windows Server provides the initiator and Microsoft MPIO framework. Every cluster host must discover the same storage consistently and use the supported DSM/path policy.
eEVOS
The built-in initiator connects shared iSCSI storage for virtualisation. eEVOS is also a standalone alternative to VMware, including integrated Backup & Disaster Recovery.
Platform references: Broadcom iSCSI port binding, Broadcom multipathing policies and Microsoft Hyper-V storage guidance.
Choose iSCSI when the host or application should own the file system
The transport choice follows the required access model. iSCSI is not a faster replacement for every SMB or NFS share.
iSCSI
Block
The storage system presents a LUN. The host formats it and controls the file system or application data structure.
- VMFS datastores
- Hyper-V cluster disks
- Database volumes
- Host-controlled snapshots and applications
SMB or NFS
File
The storage server owns the file system and presents shared directories, names, permissions and locking.
- User and departmental shares
- Shared application files
- Home directories
- File-level access by many clients
Choose the availability model before choosing the target
euroNAS is used as a practical example because it is the implementation we can document directly. The four platforms have different roles and should not be presented as interchangeable.
| Platform | iSCSI role | Multipathing | Data and availability model | Typical use |
|---|---|---|---|---|
| euroNAS Premium | Target and initiator | Supported | Standalone storage server; local ZFS data services where configured | Single storage appliance or virtual storage appliance |
| euroNAS HA Cluster | Target and initiator | Supported | Synchronous two-server mirror or shared-storage failover; optional asynchronous ZFS replication is a separate DR mechanism | Two-node automatic service failover |
| eEKAS | Target and initiator | ALUA multipath | Ceph-backed scale-out storage with distributed gateways and LUN optimisation | Scale-out block storage without a two-node capacity boundary |
| eEVOS | Built-in initiator; storage consumer | Supported | Virtualisation host or cluster consuming shared storage | VM workloads with integrated Backup & Disaster Recovery |
iSER option: current euroNAS iSCSI target workflows can enable iSER where an active RDMA network portal is available. This retains the iSCSI command and management model while moving data through an RDMA-capable path. The complete host, adapter, switch and target combination must be qualified.
euroNAS Premium
Present iSCSI alongside file and other block services on standard enterprise hardware.
HA Cluster
Coordinate protected storage, service addressing and iSCSI target failover across two nodes.
eEKAS
Distribute LUNs and optimised ALUA paths across Ceph gateway nodes with no fixed two-node scale boundary.
eEVOS
Connect compatible shared iSCSI storage through the integrated initiator.
Configure ALUA distribution and iSER without routine command-line work
These current eEKAS examples show how the IP Group determines gateway failover or ALUA behaviour and how the resulting target paths are presented.
Select gateway policy and optional iSERA distributed IP Group enables ALUA path handling; iSER can be selected when an RDMA portal is available.