VMware ESXi and vSphere Cluster Management

iSCSI Target Discovery in VMware ESXi: Static and Dynamic Methods

Learn how VMware ESXi discovers iSCSI targets, compare static and dynamic discovery, prepare VMkernel networking, validate LUNs and paths, and troubleshoot common failures.

iSCSI is a storage protocol that transports SCSI commands over an IP network. Before an ESXi host can use an iSCSI-backed VMFS datastore, it must discover the storage target, establish access to the target, detect the presented LUN, and identify the storage device correctly.

This lesson explains static and dynamic iSCSI target discovery in ESXi, the networking and authorization requirements, the normal configuration workflow, and practical validation and troubleshooting checks.

Purpose of iSCSI Target Discovery

An iSCSI target is the storage-side endpoint that presents logical storage units to authorized clients. An ESXi host acts as an iSCSI initiator, which is the client-side component that connects to targets.

Discovery gives the initiator enough information to identify reachable targets. It does not automatically grant unrestricted access. The storage system must also authorize the ESXi initiator and present the appropriate LUNs through mechanisms such as host groups, initiator access control, and LUN masking.

Discovery, login, LUN visibility, and datastores

  1. Network connectivity: The ESXi iSCSI VMkernel interface reaches the target or discovery portal over the storage network.
  2. Target discovery: ESXi learns which iSCSI targets are available, either from manually configured entries or from a discovery response.
  3. Target login: ESXi attempts to establish an iSCSI session with an authorized target. CHAP may be required.
  4. LUN visibility: The storage array presents specific LUNs to the authorized initiator.
  5. Device detection: ESXi rescans the adapter and detects the storage device and its paths.
  6. Datastore use: Only after verifying the correct device should an administrator create or mount a VMFS datastore.

A successful discovery response alone is therefore not proof that a usable datastore device is available. Both network reachability and storage-side authorization or LUN masking must be correct.

Core iSCSI Components and Names

ComponentRoleExample ValueWhere It Is Configured or Verified
ESXi iSCSI initiatorClient-side identity that opens iSCSI sessions.An initiator IQNESXi iSCSI adapter and storage-array authorization
VMkernel adapterESXi host network interface used for software iSCSI traffic.A storage VMkernel interface with an IP addressESXi networking configuration
Discovery portalEndpoint queried to learn about available targets.192.0.2.30:3260Dynamic discovery settings on the iSCSI adapter
Target portalNetwork endpoint through which a target is reached.192.0.2.20:3260Static target settings or discovery results
Target IQN or EUIIdentifier for a particular iSCSI target.iqn.2026-01.example:array.target1Storage array and ESXi target list
LUNLogical storage unit presented by a target.A numbered block deviceStorage presentation and ESXi storage devices
CHAP credentialsOptional credentials for authenticating iSCSI sessions.A configured CHAP name and secretESXi adapter and storage-array authentication settings

Portal

An iSCSI portal is a network endpoint used for iSCSI communication. It commonly consists of an IP address or resolvable host name and TCP port 3260, the standard port for iSCSI traffic. A portal identifies where communication occurs; it does not by itself identify a particular LUN.

Target, LUN, and iSCSI name

The target is the storage endpoint, while a LUN is an individual logical storage unit presented behind that target. One target can present multiple LUNs, and an array can expose multiple target endpoints.

A target normally has an iSCSI name. The most common format is an IQN, or iSCSI Qualified Name. An EUI, or Extended Unique Identifier, is another possible naming format. The target name must be entered exactly when static discovery is used.

Static Target Discovery

Static discovery means that the administrator manually enters both the target portal and the specific target iSCSI name on the ESXi initiator. For example, a configuration might contain target portal 192.0.2.20:3260 and a known target IQN.

ESXi uses this explicit information rather than asking a portal to return a list of targets. The configured target remains subject to network access, target authorization, authentication, and LUN masking.

When to use static discovery

  • Only selected targets should be configured on a host.
  • The storage design restricts or disables target enumeration.
  • The array provides a known target endpoint and exact target name.
  • Operational policy requires tightly controlled, explicit storage definitions.

Static discovery can reduce unintended target configuration, but it creates change-management work. If a target moves, its portal changes, or its IQN changes, the ESXi entry must be updated accurately. A storage adapter rescan is normally needed after adding or changing a static target configuration.

Example: one known target

  1. Confirm that the storage array provides a target portal at 192.0.2.20.
  2. Obtain the exact target IQN from the storage system.
  3. Open the intended ESXi iSCSI adapter configuration.
  4. Add a static target using the portal address and target IQN.
  5. Rescan the storage adapter.
  6. Confirm that the expected target, LUN, device identity, and paths appear.

ESXi should detect the explicitly configured target only if it is reachable and authorized. Static configuration does not bypass storage-side access controls.

Dynamic Target Discovery

Dynamic discovery means that the administrator configures one or more discovery portal addresses or host names. ESXi sends the standard iSCSI SendTargets discovery request to each configured portal.

The storage system responds with target information. ESXi can then identify available targets and attempt access to the LUNs that the storage system presents to the authorized initiator. Target visibility and LUN visibility remain governed by target-side access controls and LUN masking.

When to use dynamic discovery

  • A storage array exposes several targets through one or more discovery portals.
  • The array is designed to enumerate target endpoints through SendTargets.
  • Storage administrators expect targets or endpoints to change over time.
  • Reducing manual target-entry work is more important than specifying every target individually.

Dynamic discovery generally scales better for arrays with multiple endpoints, but it depends on the discovery service being reachable and permitted. Newly available targets or newly mapped LUNs may require a storage adapter rescan before ESXi displays them.

Example: array with several target endpoints

  1. The array provides a discovery portal at 192.0.2.30.
  2. Add that address to the dynamic discovery configuration of the ESXi iSCSI adapter.
  3. ESXi sends a SendTargets request to the portal.
  4. The array returns target information for targets that the discovery service exposes.
  5. Rescan the storage adapter.
  6. Verify the expected targets, LUNs, devices, and paths.

Static Discovery Versus Dynamic Discovery

CharacteristicStatic DiscoveryDynamic Discovery
Required administrator inputTarget portal plus the exact target name.One or more discovery portal addresses or host names.
How targets are identifiedThe administrator specifies each target directly.ESXi learns target information from the discovery response.
Use of SendTargetsNot required to identify the configured target.ESXi uses SendTargets to request target information.
Administrative effortMore manual entry and ongoing maintenance when targets change.Less manual entry, but discovery service behavior must be maintained.
Suitability for multiple targetsWorks, but each target must be entered and maintained.Well suited to arrays that expose many targets through discovery portals.
Typical use caseRestricted environments or carefully selected target endpoints.Arrays that enumerate several target endpoints through one or more portals.
Need for rescan after changesNormally rescan after adding or changing entries.Rescan after discovery configuration changes or new storage presentation.

Neither method is universally better. Choose based on storage-array behavior, security design, the desired level of target control, and operational policy.

Network Preparation for ESXi iSCSI

A software iSCSI initiator requires a VMkernel adapter. The adapter supplies the host-side network identity and path for iSCSI traffic. A supported hardware iSCSI adapter has its own implementation and configuration requirements, but it still needs reachability and storage authorization.

Network requirements

  • IP addressing: Assign an address appropriate for the storage network.
  • VLAN placement: Place the VMkernel interface in the VLAN that can reach the storage portals.
  • Layer 2 or routing: Confirm that the storage subnet is reachable according to the design.
  • MTU consistency: Use consistent MTU settings across the complete path when a larger frame size is planned. Do not enable jumbo frames on only part of the path.
  • DNS: Provide working DNS resolution when a portal is entered as a host name.
  • Traffic separation: Separate storage traffic from management and virtual-machine traffic when the design requires isolation or predictable performance.
  • Firewall rules: Permit the required iSCSI communication, normally TCP port 3260, between the VMkernel network and storage endpoints.

The VMkernel adapter must reach the discovery portal for dynamic discovery and the target portal for static discovery or target login. A correctly entered target name cannot compensate for a broken VLAN, route, MTU configuration, DNS record, or firewall rule.

End-to-End Discovery Workflow in ESXi

  1. Identify the adapter: Select the intended software iSCSI adapter or supported hardware iSCSI adapter.
  2. Record the initiator identity: Obtain the ESXi initiator IQN and provide it to the storage administrator for authorization.
  3. Prepare networking: Verify the storage VMkernel adapter, IP address, VLAN, MTU, routing, DNS, and firewall access.
  4. Configure discovery: Add a portal and exact target name for static discovery, or add discovery portal addresses or names for dynamic discovery.
  5. Configure storage access: Authorize the initiator, apply any required authentication, and map the intended LUNs.
  6. Rescan storage: Rescan the iSCSI adapter after discovery configuration or storage presentation changes.
  7. Validate results: Check discovered targets, sessions, paths, LUNs, and device identities.
  8. Create or mount storage: Create or mount a VMFS datastore only after confirming that the device is the intended volume.

Validation and Operational Checks

  • Verify that the configured discovery address is reachable from the intended VMkernel interface.
  • Confirm that the expected target IQNs or EUI identifiers appear after discovery.
  • Confirm that expected LUNs are visible and that unauthorized LUNs are not visible.
  • Check the number and state of storage paths against the design.
  • Verify that each intended target portal and storage interface is reachable.
  • Confirm that the detected device has the expected size, identifier, and presentation state.
  • Review the array's initiator authorization, host group membership, LUN masking, and authentication settings.

Path count is especially important when the design uses multiple storage interfaces or multipathing. A target can be visible while one or more intended paths are missing.

Access Control and Security Context

Discovery is an information and connection step, not a replacement for access control. Storage systems commonly control access using the initiator IQN, target authorization rules, host groups, and LUN masking.

LUN masking limits which LUNs are presented to particular initiators. If a target is visible but an expected LUN is absent, review the storage-side mapping rather than assuming that discovery failed.

CHAP, or Challenge-Handshake Authentication Protocol, is an optional iSCSI authentication mechanism. Configure it only when it is part of the storage design, and ensure that the settings match on both ESXi and the array.

Use dedicated storage networking where appropriate, restrict discovery portal access with VLAN and firewall controls, and protect authentication secrets. Network reachability should be intentional rather than broadly permitting access to every storage endpoint.

Discovery Failure Checklist

SymptomLikely CauseVerificationCorrective Direction
No targets discoveredIncorrect portal, network failure, blocked TCP port, DNS problem, or SendTargets not permitted.Check the portal, VMkernel reachability, VLAN, routing, DNS, firewall, and array discovery service.Correct the network or portal configuration and rescan.
Target appears but no LUNs appearMissing initiator authorization, incorrect host group, or LUN masking.Compare the ESXi initiator IQN with the storage mapping and review presented LUNs.Authorize the correct initiator and map the intended LUNs, then rescan.
Host name cannot be usedDNS resolution or DNS reachability is unavailable.Verify the fully qualified name resolves from the storage network context.Correct DNS configuration or use a verified numeric address according to policy.
Only some paths are visibleMissing portal reachability, VLAN or MTU mismatch, incomplete port binding, or unavailable array port.Compare storage interfaces, subnets, VLANs, MTUs, target portals, and path design.Restore the missing network or storage endpoint and rescan.
Discovery succeeds but datastore is unavailableDevice not rescanned, wrong device selected, path issue, or VMFS/storage problem.Verify device identity, paths, filesystem state, and datastore mounting information.Rescan and correct the storage or datastore configuration without formatting the wrong device.

Practical Troubleshooting Scenarios

No targets through dynamic discovery

  • Confirm the discovery portal address or host name is correct.
  • Verify VMkernel-to-storage reachability and VLAN configuration.
  • Check DNS resolution if a host name was entered.
  • Confirm that the target service is listening on TCP port 3260.
  • Verify that the storage system supports and permits SendTargets discovery.

A static target does not appear

  • Validate the target portal address.
  • Compare the entered target IQN or EUI character by character with the storage configuration.
  • Confirm that the ESXi initiator is authorized.
  • Rescan the storage adapter after correcting the entry.

The target is visible but LUNs are missing

  • Verify that the LUNs are mapped to the ESXi initiator identity.
  • Review LUN masking and host group membership.
  • Confirm that the correct initiator IQN was authorized.
  • Rescan after changing LUN presentation.

One host works and another does not

  • Compare VMkernel IP settings, VLAN assignments, MTU values, and routing.
  • Compare initiator authorization and LUN mappings on the array.
  • Compare discovery portals, static target identifiers, and authentication settings.
  • Confirm that both hosts use the intended iSCSI adapter.

Storage paths are incomplete

  • Verify reachability to every intended storage interface and target portal.
  • Review multipath network design and port-binding requirements where applicable.
  • Check that each ESXi storage interface has the expected subnet and VLAN access.
  • Review storage-array port availability and host connectivity.

Exam-Relevant Notes

  • ESXi is the iSCSI initiator; the storage system supplies the iSCSI target.
  • A target is not the same thing as a LUN. A target can present multiple LUNs.
  • Static discovery requires a portal and an explicit target name.
  • Dynamic discovery configures a discovery portal and uses SendTargets.
  • Discovery does not bypass initiator authorization or LUN masking.
  • A software iSCSI initiator requires a VMkernel adapter.
  • TCP port 3260 is the standard iSCSI communication port.
  • A storage rescan is normally required after discovery or LUN-presentation changes.
  • Always verify storage identity before formatting a device or creating a datastore.

Summary

iSCSI target discovery allows an ESXi initiator to learn which storage endpoints it may use. Static discovery explicitly names each portal and target, while dynamic discovery queries a discovery portal with SendTargets. Both methods depend on correct VMkernel networking, reachable portals, storage-side authorization, LUN masking, and any required CHAP settings.

The reliable workflow is to prepare the storage network, identify and authorize the initiator, configure the selected discovery method, rescan the adapter, verify targets and paths, confirm the correct LUN identity, and only then create or mount a VMFS datastore.

For broader ESXi administration, see the VMware ESXi online course and the VMware ESXi overview.