What Is an iSCSI LUN? Targets, Initiators and MPIO

An iSCSI LUN (logical unit number) is the address of one logical unit, normally a block volume, inside an iSCSI target. A host’s initiator logs in to the target over TCP, on port 3260 by default, and every LUN mapped to that host appears as a local raw disk that the host partitions and formats itself.

iSCSI carries SCSI commands over TCP/IP. That single sentence explains most of its behaviour, including the parts that surprise people coming from file sharing protocols. The client is not asking a server for a file. It is issuing block level commands to what it believes is a locally attached disk, and the network is only the transport.

What an iSCSI LUN is

A LUN is a logical unit number: the SCSI address used to identify a logical unit within a target. Administrators also use “LUN” as shorthand for the storage volume presented at that address. RFC 7143 distinguishes the target, which can contain multiple logical units, from the LUN carried in a command to select one of them. On the wire that LUN is a 64-bit field in the PDU header, formatted according to the SCSI Architecture Model: a SCSI address that iSCSI carries, not something iSCSI invented.

For a disk-like logical unit, the initiator sees a block device and supplies the filesystem or volume manager. Creating a target IQN alone does not provide a disk: the target also needs backing storage and a mapping that makes that storage visible to the intended initiator.

Numbering normally starts at zero. In Red Hat’s targetcli walkthrough for RHEL 9, the first LUN created in a target portal group is reported as LUN 0, and the next two, backed by a block device and a file, become LUN 1 and LUN 2. LUNs are created read-write by default.

Two targets can each expose LUN 0 without exposing the same disk. Conversely, one volume can appear through several paths. Confirm the device identity before formatting; a LUN number alone is not a globally unique volume identifier.

LUN vs iSCSI: what is the difference?

iSCSI is the transport protocol and a LUN is the destination of its commands. iSCSI moves SCSI commands across a TCP/IP network; a LUN is the SCSI address of one logical unit inside a target. They are not alternatives: every useful iSCSI target exposes at least one LUN, and LUNs also exist on other SCSI transports.

An “iSCSI LUN” is therefore just a LUN reached over iSCSI. To the host’s SCSI layer it looks like any other logical unit: lsscsi lists each SCSI device with an [H:C:T:L] tuple of host, controller, target and LUN.

What is an iSCSI target?

An iSCSI target is the storage-side endpoint: a named iSCSI node that listens for initiator logins and presents one or more logical units to them. RFC 7143 describes a SCSI target device as containing one or more target ports and one or more LUs, and makes TCP 3260 the default port.

Each LUN is the thing the host sees as a raw disk. It can be backed by a file, a logical volume, a ZFS zvol, a whole physical disk or an array volume, and the initiator neither knows nor cares which.

The target can be an array, a NAS appliance or a server running target software, which on Red Hat Enterprise Linux is the kernel’s LIO target, managed with targetcli. Red Hat’s RHEL 9 guide lists four backstore types: fileio for regular files used as disk images, block for local block and logical devices, pscsi for SCSI pass-through, and ramdisk for temporary RAM-backed devices. Its default portal binds 0.0.0.0:3260, so the target listens on every address until you restrict it.

Software targets publish ceilings worth checking before designing around one. Microsoft’s iSCSI Target Server scalability limits, checked October 2026, are 256 target instances per server, 256 LUNs per target (128 on Windows Server 2012, enforced), 512 LUNs per server, 544 simultaneous sessions per target and four tested MPIO paths, with fixed .vhdx virtual disks up to 64 TB. The same page lists hardware iSCSI offload as unsupported on that target.

What is an iSCSI initiator?

An iSCSI initiator is the client end: software or hardware on the host that logs in to a target and originates the SCSI commands. The term comes from SCSI: RFC 7143 notes that clients of a SCSI interface are called initiators and the other endpoint is the target, so SCSI and iSCSI initiators play the same role.

Initiators come in three forms. Broadcom’s vSphere documentation names them for ESXi hosts, but the split describes any platform:

Software initiators need no specialised hardware: VMware’s software adapter is built into the VMkernel, and the Microsoft iSCSI Initiator connects a Windows host to an iSCSI array over ordinary Ethernet NICs.

How targets and initiators are named

Both ends can be named with an iSCSI qualified name, or IQN. Its format is iqn.YYYY-MM.reversed-domain:unique-suffix, with a date establishing when the naming authority owned the domain. RFC 7143 also defines eui. and naa. name formats and caps a name at 223 bytes of UTF-8; its own example is iqn.2001-04.com.example:storage.tape1.sys1.xyz. IQNs are identifiers, not addresses, and targets can use them to control which initiators see which LUNs. A worked example of that mapping on a NAS-class box, including which backing store to choose, is in Unraid, TrueNAS and Synology target setup; for a zvol-backed target, see TrueNAS iSCSI target setup, zvol to login.

Keep an inventory of target IQNs, portal addresses, LUN mappings and owning hosts outside the target configuration. On Linux, check /etc/iscsi/initiatorname.iscsi after cloning a host: the open-iscsi documentation requires distinct initiator names. Copy the actual name into the target’s allow-list. Store CHAP secrets in a credential store separately from that inventory.

Discovery and authentication

The initiator connects to a portal, which is an IP address and port on the target, and performs discovery. The target responds with the list of targets it is willing to advertise. The initiator then logs in to a specific target and begins a session.

Access control has two independent layers and both matter. Initiator masking restricts which IQNs may access a given LUN. CHAP provides authentication during login. One way CHAP authenticates the initiator to the target. Mutual CHAP additionally authenticates the target to the initiator, which is what prevents a host from attaching to an impostor target.

Discovery and login are separate exchanges: a target that lists but refuses login warrants checking identity and authentication, as well as reachability of the advertised portal. That split, and how to read it, is the starting point of iSCSI troubleshooting for login, timeout and path errors.

Neither layer encrypts traffic. iSCSI data crosses the wire in the clear unless you wrap it in IPsec or confine it to a trusted network segment. Confining it is the usual answer.

How to list iSCSI LUNs with iscsiadm

iscsiadm has no dedicated “list LUNs” mode. Log in first, then run iscsiadm -m session -P 3: Red Hat’s initiator documentation says it shows the session or device state, session ID, some negotiated parameters and the SCSI devices accessible through each session. Discovery output lists portals and target IQNs, not LUNs.

On a Linux host running open-iscsi:

1. sudo iscsiadm -m session prints one line per session: driver [sid] target_ip:port,target_portal_group_tag target_name. The same IQN on two portals means two paths.
2. sudo iscsiadm -m session -P 3 adds the SCSI devices behind each session; the iscsiadm manual documents -P as the tree print level.
3. lsscsi -s lists each SCSI device’s [H:C:T:L] tuple and size. The last number is the LUN.
4. ls -l /dev/disk/by-path/ | grep iscsi shows links named ip-<address>:<port>-iscsi-<iqn>-lun-<number>, the pattern in Red Hat’s persistent naming reference.
5. After mapping a new LUN on the target, sudo iscsiadm -m session -R rescans all sessions (add -r with a session ID for just one), then repeat steps 3 and 4.

Expect duplicates when multipathing is working. Each path is its own SCSI device, so a LUN reached through two portals appears twice in lsscsi and twice under /dev/disk/by-path/, but once in multipath -ll. Do not copy a /dev/sdX name into configuration either: Red Hat notes that traditional names are subject to change when devices are added or removed.

On Windows, Microsoft’s Get-Disk reference filters disks on the iSCSI bus and pipes them to Get-IscsiSession to show the session behind each:

Get-Disk | Where-Object -FilterScript {$_.BusType -Eq "iSCSI"} | Get-IscsiSession | Format-Table

Network design

Treat the storage network as a separate network. A dedicated VLAN or dedicated physical interfaces keep general traffic from competing with storage traffic, and keep the storage fabric out of reach of clients that have no business on it.

Flow control and switch buffering matter more here than on general networks, because TCP retransmission on a storage path shows up to applications as latency spikes on a disk. Larger frame sizes can reduce per packet overhead, but every device in the path must agree on the setting, and a mismatch produces silent fragmentation or dropped frames that are painful to diagnose.

Before adding interfaces, compare the network and media ceilings with the iSCSI Throughput and MPIO Calculator for a given path count, block size and storage class.

MPIO is not link aggregation

This is a recurring architectural error. Link aggregation bonds physical links into one logical link, and a single TCP connection still traverses one member link, so a single iSCSI session gains no bandwidth from it.

Multipath I/O works at the SCSI layer instead. The initiator establishes independent sessions over independent paths, recognises that the LUNs arriving on each path are the same device, and presents one device to the operating system. The multipath layer then distributes I/O across paths and fails over when one dies. Choose the subnet layout for the host platform and the storage vendor’s supported topology. Microsoft’s Windows MPIO guidance calls for separate network adapters; verify the physical paths and failover rather than treating subnet count alone as proof of redundancy.

Connect the initiator and check persistence

The open-iscsi workflow separates discovery from login. Discover each intended storage portal, verify the target IQN returned, then establish the sessions required by the host’s multipath configuration. Check the target’s host mapping before using a newly visible disk.

For sessions that should reconnect at boot, review the saved node’s node.startup setting. The upstream configuration defaults to manual; the README documents automatic for startup login. Changing the default configuration does not update existing node records. Verify the saved records and the host’s startup service configuration together, then restart during a maintenance window with disposable data.

Verify MPIO failover before using the LUN

On Linux, inspect multipath -ll for one map per volume and the expected paths. On Windows, Microsoft’s MPIO guidance calls for separate network adapters and checks that the device has multiple paths. Use the array’s supported path grouping and policy; an ALUA array can distinguish optimized and non-optimized access, so counting sessions alone does not establish that all paths should carry equal traffic.

For the Windows commands, configure a Windows Server iSCSI target with CHAP and MPIO before checking path failover.

In a planned validation using disposable data, interrupt one path, confirm the remaining path carries I/O, restore it, and repeat for the other path. Record the interruption and recovery behavior. This is a procedure for the reader to perform, not a measurement made by this site.

Also decide what should happen when every path is unavailable. Review the initiator replacement timeout together with the multipath queueing policy and the application’s timeout expectations. The login and path troubleshooting guide covers those timers. A successful login does not validate reconnection after reboot or recovery from path loss.

Common mistakes

Mounting the same LUN read write on two hosts with an ordinary filesystem. Block storage does no arbitration, so both hosts cache and write independently and the filesystem corrupts. Sharing a LUN requires a cluster aware filesystem or a clustered volume manager. When several machines genuinely need the same data at once, a file protocol is the right tool instead, and the ownership models are compared in iSCSI vs NFS vs SMB.

Others worth avoiding: assuming multiple sessions prove independent physical paths without checking the host’s supported topology; leaving CHAP disabled on a routable network; thin provisioning past physical capacity with no monitoring, which turns a full backing store into write failures on every attached host; and forgetting that snapshots on the target are crash consistent unless the host is quiesced first.

On a LIO target, adding a LUN after ACLs exist maps it to every existing ACL automatically, which Red Hat’s target guide flags as a security risk. Setting auto_add_mapped_luns=false makes each mapping a deliberate step.

Where to go next

• Build a target on consumer NAS hardware: Unraid iSCSI target setup.
• Decide whether block storage is the right choice at all: iSCSI vs NFS vs SMB.
• Weigh block against file storage for a home server: NFS vs iSCSI for a homelab.
• Diagnose a session that will not come up, or a path that keeps dropping: iSCSI troubleshooting: login, timeout and path errors.
• Size the fabric: iSCSI Throughput and MPIO Calculator.

FAQ

is an iscsi target the same as a lun?

No. A target is the named endpoint an initiator logs in to, identified by an IQN and reached through a portal, usually on TCP 3260. A LUN is one logical unit inside that target. One target can hold many LUNs, and a host only sees the LUNs that the target maps to its initiator name.

how many luns can an iscsi target have?

It depends on the target software rather than the protocol, whose LUN field is 64 bits wide. Microsoft’s iSCSI Target Server enforces 256 LUNs per target (128 on Windows Server 2012) and is tested to 512 per server. Other targets set their own limits, so check the vendor’s documentation before planning a layout.

what port does iscsi use?

iSCSI uses TCP port 3260 by default, the well-known port assigned by IANA and the only default RFC 7143 allows. Port 860 is also registered as the iSCSI system port, but it is used only when specified explicitly. Firewalls between initiator and portal need 3260 open, or whichever port the target was configured with.

can two servers share the same iscsi lun?

Only with a cluster-aware filesystem or a clustered volume manager. iSCSI does no arbitration between hosts, so two servers mounting an ordinary filesystem read-write on one LUN cache and write independently, and the filesystem corrupts. If several machines need the same files at once, a file protocol such as NFS or SMB is the safer choice.