VMware ESXi and vSphere Cluster Management

iSCSI SAN Components in VMware ESXi

Learn how iSCSI SAN components work with VMware ESXi, including initiators, targets, LUNs, portals, IQNs, discovery, access control, and multipathing.

iSCSI is a method for providing block storage over an IP network. This lesson explains the components involved when a VMware ESXi host connects to an iSCSI storage system, how those components are identified, and how storage becomes available to ESXi.

Prerequisites include basic TCP/IP networking, VLANs, routing, TCP ports, block storage, SCSI terminology, and ESXi VMkernel networking.

What iSCSI Is

iSCSI stands for Internet Small Computer System Interface. It carries SCSI commands and storage data inside TCP/IP packets.

SCSI is a command and protocol model used to communicate with storage devices. iSCSI transports that model across an IP network, allowing a host to use remote block storage without requiring a dedicated Fibre Channel SAN.

A SAN, or storage area network, provides block-level storage to hosts. With iSCSI, the SAN traffic uses Ethernet and TCP/IP networking. The storage still behaves as a block device to ESXi even though the physical connection is an IP network connection.

High-Level iSCSI SAN Architecture

An iSCSI environment has a host-side endpoint, a network path, and a storage-side endpoint.

  • The ESXi host contains an iSCSI initiator.
  • The initiator uses an ESXi VMkernel network interface and an IP network.
  • The initiator connects to a storage-side target portal.
  • The portal provides access to an iSCSI target.
  • The target presents one or more LUNs.
  • ESXi discovers an authorized LUN and uses it as block storage.

The basic traffic path is:

ESXi iSCSI initiator -> VMkernel interface -> IP network -> target portal -> iSCSI target -> LUN

The storage system is the physical appliance or server. Targets and LUNs are logical objects configured on that system. For example, one array can contain physical disks and storage pools while exposing several targets, each with several LUNs.

iSCSI SAN Component Roles

Storage system — Location: physical storage appliance or server. Primary role: supplies disks, pools, volumes, targets, and LUNs. Key identifiers: management identity and configured storage objects. Relationship: can contain and expose multiple targets and LUNs.

iSCSI target — Location: storage side. Primary role: logical endpoint that receives SCSI commands and presents LUNs. Key identifier: target IQN. Relationship: exports one or more LUNs to authorized initiators.

LUN — Location: inside the target's storage presentation. Primary role: logical SCSI block device. Key identifier: LUN number within the target context. Relationship: mapped or masked to selected initiators.

iSCSI initiator — Location: ESXi host. Primary role: sends SCSI commands to targets. Key identifier: initiator IQN. Relationship: logs in to target portals and accesses permitted LUNs.

iSCSI portal — Location: an IP network endpoint on the initiator or target side. Primary role: provides a network address for iSCSI communication. Key identifiers: IP address and TCP port, commonly 3260. Relationship: connects an initiator session to a target.

IQN — Location: configuration of an initiator or target. Primary role: identifies an iSCSI endpoint. Key identifier: the IQN itself. Relationship: used for discovery, authentication, and LUN masking.

iSNS — Location: a service on the IP network. Primary role: centrally registers and helps discover iSCSI devices. Key identifier: the iSNS service address. Relationship: can provide centralized discovery and management information.

The iSCSI Storage System

An iSCSI storage system is the physical appliance or server that provides storage over the network. It may contain disks, RAID groups, storage pools, logical volumes, snapshots, targets, and LUNs.

Physical capacity is usually organized into one or more internal storage structures. The administrator then creates logical storage objects and presents them through iSCSI targets. A single storage system can expose multiple targets and multiple LUNs.

Do not treat the storage system, target, and LUN as interchangeable terms:

  • The storage system is the physical platform.
  • The target is a logical storage-side endpoint.
  • The LUN is a logical block device exported through a target.

iSCSI Targets

An iSCSI target is the logical storage-side endpoint that receives SCSI commands from initiators over TCP/IP. The target processes login requests, sessions, commands, and access permissions.

A target can export one or more LUNs. The LUN number is meaningful within the target context, so “LUN 1” is not necessarily a globally unique identifier across every target in the environment.

Storage administrators normally configure access control so that only approved initiators can use selected LUNs. This is commonly called LUN masking or storage presentation control. A target may exist and be reachable while a particular initiator is still denied access to some or all of its LUNs.

LUNs

LUN means Logical Unit Number. In practical iSCSI administration, a LUN is the logical block-storage device presented through SCSI and iSCSI.

A LUN is identified within a target and is presented to approved initiators. After discovery, ESXi can recognize the LUN as a storage device. The device may then be used to create a VMFS datastore, which is a VMware file system for virtual machine files.

In an approved use case, a LUN can also be used as the backing storage for a Raw Device Mapping. RDM allows a virtual machine to access a raw storage LUN while VMware retains a mapping file that describes the connection.

iSCSI Initiators

An iSCSI initiator is the logical host-side endpoint that issues SCSI commands to an iSCSI target. In a VMware environment, the initiator resides on an ESXi host.

ESXi can use a software iSCSI initiator, where host software processes iSCSI traffic using standard network adapters. It can also use a hardware or offload iSCSI adapter, where an adapter performs some or much of the iSCSI processing. The implementation differs, but both provide an initiator identity and communicate with targets.

Each initiator has an identity, normally an initiator IQN. Storage access control uses this identity to decide which targets and LUNs the host may access.

iSCSI Network Portals

An iSCSI portal is an IP-addressable network endpoint used for iSCSI communication. A portal commonly consists of an IP address and TCP port. The standard iSCSI port is usually TCP 3260.

Initiators and targets may use one or multiple portal IP addresses. Multiple target portals can provide separate network paths to the same storage. When ESXi is configured correctly, those paths form the foundation for multipathing, which uses multiple storage paths for availability and, depending on policy and configuration, load distribution.

Target portal example: 10.20.30.50:3260

An IP address describes where a service is reachable. It does not replace the identity of the target or initiator.

iSCSI Qualified Names

An iSCSI Qualified Name, or IQN, is an iSCSI identifier for an initiator or target. IQNs are designed to provide globally unique naming and are used during discovery, authentication, login, and LUN masking.

A general IQN contains a date-based naming authority followed by a reverse-domain-style authority and a unique suffix:

iqn.yyyy-mm.reverse-domain:unique-suffix

Examples include:

Initiator IQN: iqn.1998-01.com.example:esxi01
Target IQN:    iqn.2024-01.com.example.storage:array01.target01

The date identifies when the naming authority owned or controlled the domain name. It is part of the naming format; it is not necessarily a creation date for the device.

An IQN is not an IP address. The IQN identifies an iSCSI endpoint, while the portal IP address identifies a network location used to reach it. A target may keep the same IQN while its portal IP changes during a network migration.

iSCSI Identifiers and Addresses

Initiator IQN — Example: iqn.1998-01.com.example:esxi01. Identifies the ESXi initiator. It normally remains stable unless deliberately changed. Used for authorization, masking, and authentication.

Target IQN — Example: iqn.2024-01.com.example.storage:array01.target01. Identifies the logical storage endpoint. It can remain the same while network addresses change. Used for discovery and target selection.

Portal IP address — Example: 10.20.30.50. Identifies a network location. It can change during network or storage migrations. Used to establish TCP connectivity.

TCP port 3260 — Example: 3260. Identifies the usual TCP service port for iSCSI. It can be changed by some implementations, but both sides must use the configured value. Used with the portal IP address.

LUN number — Example: LUN 1. Identifies a logical unit within a target context. It can vary when storage is remapped. Used to select a presented block device.

Discovery and iSNS

Discovery allows an initiator to find available target portals and targets. ESXi administrators commonly use static discovery or dynamic discovery.

  • Static discovery: the administrator enters a target portal address, usually including its IP address and TCP port. ESXi contacts that portal and learns the target information.
  • Dynamic discovery: the administrator enters a discovery portal. The target service returns information about available targets, commonly through SendTargets discovery.
  • iSNS: an iSCSI Naming Service can centrally register, discover, and help manage iSCSI devices.

iSNS provides a directory-like service for iSCSI devices. Initiators and targets register with the service, and administrators can use it to support centralized discovery and management. iSNS is uncommon in many current deployments, where static or dynamic discovery is more typical, but its conceptual role is important.

Component Relationships and Access Flow

  1. The ESXi administrator configures an iSCSI VMkernel adapter or selects a suitable host-side network configuration.
  2. ESXi has an initiator with an initiator IQN.
  3. The administrator records that IQN in the storage system's access-control configuration.
  4. The storage administrator creates or selects a target and maps selected LUNs to the authorized host or host group.
  5. ESXi uses static discovery, dynamic discovery, or iSNS to find a target portal and target IQN.
  6. The initiator connects to the portal over TCP/IP and performs an iSCSI login.
  7. The target authenticates or authorizes the initiator identity and exposes only permitted LUNs.
  8. ESXi rescans its storage adapters and discovers the presented LUN as a block device.
  9. The administrator creates a VMFS datastore or configures an approved raw device mapping use case.

Network reachability is necessary but not sufficient. An ESXi host may be able to reach a portal and still see no LUNs if the initiator IQN is not authorized, the LUN is not mapped, masking is incorrect, or a rescan has not occurred.

Practical Example: Basic ESXi-to-Storage Connection

Assume an ESXi host has an initiator IQN and a storage array publishes a target with this portal:

10.20.30.50:3260
  1. The administrator adds the ESXi initiator IQN to the target's authorized host list.
  2. The storage administrator maps LUN 1 to that host.
  3. ESXi discovers the target through configured discovery.
  4. The initiator logs in to the target portal.
  5. ESXi discovers LUN 1 as a block device.
  6. The administrator formats the LUN as a VMFS datastore for virtual machine files.

Practical Example: Multiple LUNs from One Target

One target may export separate LUNs for a production datastore, a test datastore, and a backup repository. An authorized ESXi initiator can discover all three through the same target.

Storage-side masking can present the production LUN only to production hosts and restrict the test LUN to test hosts. This separation is enforced by storage presentation and authorization, not simply by placing devices on the same IP network.

Practical Example: Redundant iSCSI Connectivity

An ESXi host can use two storage-network adapters and two VMkernel interfaces. The storage system can expose two target portals on separate network paths. Both paths can lead to the same target and LUNs.

With suitable ESXi and storage configuration, multipathing allows the host to maintain access if one adapter, switch path, portal, or network segment fails. Separate paths should be validated independently; merely having two cables does not guarantee usable redundancy.

Conceptual ESXi Configuration Sequence

  1. Create or select a dedicated VMkernel adapter for iSCSI traffic.
  2. Enable or select a software iSCSI initiator or hardware/offload iSCSI adapter.
  3. Record the ESXi initiator IQN.
  4. Configure the storage target to permit that initiator IQN.
  5. Map the intended LUNs to the authorized host or host group.
  6. Add target portal addresses through static or dynamic discovery, or configure iSNS if the environment uses it.
  7. Rescan the storage adapters.
  8. Verify discovered devices and available paths.
  9. Create a VMFS datastore or configure an approved raw device mapping use case.

Troubleshooting iSCSI Components

The ESXi Host Cannot Discover an iSCSI Target

  • Check for an incorrect target portal IP address or TCP port.
  • Verify IP connectivity between the ESXi iSCSI VMkernel interface and the target portal.
  • Check VLAN, routing, firewall, and switch configuration.
  • Review static or dynamic discovery settings.
  • Confirm that the target service is available and listening on the expected port.

Verify the VMkernel interface's addressing, confirm reachability to the portal, check the target's listening service, and review the results of a storage rescan.

The Target Is Visible but No LUNs Appear

  • The target may not have any LUNs mapped to it.
  • LUN masking may not authorize the ESXi initiator IQN.
  • The LUN may be unavailable or already claimed because of a storage-side condition.
  • ESXi may not have completed a storage rescan.

Compare the ESXi initiator IQN with the storage access-control entry. Verify LUN-to-target mapping and host or host-group membership, then rescan storage and inspect device visibility.

Connectivity Is Lost After a Target IP Change

  • Static or discovery records may still reference the former portal address.
  • Routes or VLAN access to the new portal may be missing.
  • Only one portal or path may have been configured.

Update the configured portal address, verify connectivity to the new address, and confirm that redundant portals and paths are configured where required. Remember that changing a portal IP changes the network location, not necessarily the target IQN.

Only One Path Is Available

  • A second VMkernel interface or storage NIC path may be missing.
  • The storage array may not expose a second reachable portal.
  • Network segmentation may block one path.
  • Multipathing configuration may not recognize the available paths.

Validate each initiator-side path independently, verify both target portals and their network associations, and review ESXi path visibility for the LUN.

Exam-Relevant Summary

  • iSCSI carries SCSI commands and data over TCP/IP.
  • An initiator is the host-side endpoint; a target is the storage-side endpoint.
  • A portal is an IP address and TCP port used for iSCSI communication, commonly TCP 3260.
  • A LUN is a logical block device exported through a target.
  • An IQN identifies an initiator or target; it is not an IP address.
  • LUN masking controls which initiators can see specific LUNs.
  • Discovery finds target portals and targets; it does not by itself grant LUN access.
  • Multiple portals and paths provide the foundation for multipathing.
  • A reachable target can still expose no LUNs if authorization or storage presentation is incorrect.

For related study, see iSCSI SAN components.