VMware iSCSI Datastore Setup Guide (2025)

VMware iSCSI datastore setup is the process of making an ESXi host see LUNs exposed by an iSCSI target and use them as datastore storage. The short answer is this: in the November 24, 2025 context, a safe iSCSI datastore setup requires the software iSCSI adapter to be enabled, the right discovery model to be chosen, the ESXi host IQN and storage ACL to match correctly, the vmkernel network path to be intentionally designed, and iSCSI port binding to be applied properly when multipathing is needed. This guide is written for teams that want to set up iSCSI storage without relying on guesswork.

Quick Summary

Broadcom KB 312779 says that when iSCSI storage is not visible, common causes include wrong target IP + IQN, incorrect ACL/IQN authorization, or bad CHAP settings.
The same KB says a storage rescan is required after correcting those settings.
Broadcom KB 429518 says that for iSCSI multipathing on multiple vmkernel ports in the same subnet, explicit port binding is required.
Broadcom KB 421153 shows that vmkernel ports used for iSCSI port binding become an unsupported design if Management service is also enabled on them.
Broadcom KB 391517 highlights the importance of testing the real storage path with vmkping -I <vmk#>, not just generic connectivity checks.
Broadcom KB 409088 shows that after reinstalling ESXi, the software iSCSI adapter IQN can change, which can silently break storage access at the array ACL layer.

What Exactly Is an iSCSI Datastore?

An iSCSI datastore is created when ESXi accesses block storage over IP through an iSCSI target and uses those exposed LUNs as datastore storage. It is not a file-share model like NFS. It is closer to the VMFS-style block-storage model, but carried across Ethernet and IP.

The main ingredients are:

a software or hardware iSCSI adapter on ESXi
storage target IP addresses
target IQN identity
LUN presentation
the vmkernel storage network path

In practice, iSCSI datastore setup is not just “a LUN exists.” Identity, network, and storage authorization all have to line up.

What Are the Main Building Blocks of iSCSI Datastore Setup?

A successful setup depends on these parts working together:

Software iSCSI Adapter: the initiator layer on ESXi
Dynamic or Static Discovery: how ESXi finds storage targets
IQN / ACL matching: whether the array actually authorizes the host
VMkernel ports: which network path iSCSI traffic will use
Port binding: the binding model needed for multi-vmk multipathing

If any one of these is wrong, targets may appear without usable datastores, or LUNs may never show up at all.

How Do You Set Up a VMware iSCSI Datastore?

1. Enable the Software iSCSI Adapter

The first step is confirming that the software iSCSI adapter is enabled on the ESXi host. Without it, discovery and login never really begin.

Once enabled, record the host initiator IQN. Broadcom KB 409088 shows that after reinstalling ESXi, this IQN can change. That means relying on an old host record on the storage array can quietly break access.

2. Validate IQN and ACL Authorization on the Storage Side

According to Broadcom KB 312779, one of the strongest reasons targets or LUNs do not appear is that the ESXi host IQN is not properly authorized on the array.

These checks should be explicit:

is the correct host IQN registered on the array
is the correct volume or LUN presented to that host
if shared access is intended, is multi-host access enabled where needed
if CHAP is in use, do the credentials match

3. Enter the Discovery Method Correctly

If you use Dynamic Discovery or Static Discovery, the target IP and target IQN details must be exact. Broadcom KB 312779 says incorrect target IP or target name entries directly cause visibility problems.

Small data-entry mistakes can lead to:

targets not showing up
LUNs never appearing
rescans returning no usable devices

4. Validate the VMkernel Storage Path

iSCSI datastore setup is not just entering target information. You also need proof that the ESXi host can reach storage through the intended vmkernel interface.

Broadcom KB 391517 shows why generic connectivity checks are not enough. Testing from the correct interface with vmkping -I <vmk#> <target_ip> is a far stronger validation step.

Before proceeding, answer these:

which vmkernel port will carry iSCSI traffic
are VLAN and uplink assignments correct
if jumbo MTU is expected, is it consistent end to end

5. Rescan and Check Device Visibility

Once IQN, discovery, and networking are correct, perform a storage adapter rescan. Broadcom KB 312779 is explicit that a rescan should follow configuration corrections.

The goal is not only seeing a target. The goal is seeing the right LUNs on the right host.

6. Create the Datastore or Mount the Existing One

After the device becomes visible, you can create a new VMFS datastore or mount an existing datastore to the host. If an existing datastore is unexpectedly missing on some hosts, mount state should be reviewed separately.

When Is Port Binding Required?

Port binding becomes critical when you want iSCSI multipathing across multiple vmkernel interfaces. Broadcom KB 429518 explains that when multiple vmkernel ports exist in the same subnet, ESXi does not automatically distribute storage traffic across them without explicit iSCSI port binding.

That leads to a few practical rules:

each vmkernel should ideally map to one active uplink
the Network Port Binding section under the software iSCSI adapter must be configured correctly
the Paths view should confirm that both paths are active

One more critical point: Broadcom KB 421153 shows that vmkernel ports used for iSCSI port binding should not also carry Management service. The same-subnet exception is specific to iSCSI port-binding design, not a general-purpose vmkernel pattern.

Most Common iSCSI Setup Errors

Targets or LUNs Do Not Show Up

Broadcom KB 312779 points to the usual causes:

wrong target IP or IQN
incorrect ACL authorization
CHAP mismatch
the volume not being presented to the host at all

Connectivity Looks Fine but the Real Storage Path Is Wrong

Broadcom KB 391517 is why testing from the correct vmkernel interface matters. Generic network reachability and real iSCSI path health are not the same thing.

Port Binding Exists but the Design Is Still Unstable

Broadcom KB 421153 marks iSCSI port-binding designs with Management service enabled on those vmkernel ports as unsupported.

Datastores Disappear After Reinstalling ESXi

Broadcom KB 409088 shows that reinstalling ESXi can change the host IQN. If the storage array is still authorizing the old IQN, access can disappear.

What Are iSCSI Datastore Best Practices?

1. Never Assume the IQN Will Stay the Same Forever

Host reinstall or adapter recreation can change the initiator identity. Storage ACLs must always match the current host IQN.

2. Verify Discovery Entries Even If They Were Copied

Wrong IPs or target IQNs remain one of the most common silent setup failures.

3. Use Port Binding Only in the Official Model

If multipathing is required, follow the supported port-binding design. Do not mix in Management service or ambiguous uplink usage.

4. Test the Network from the Real VMkernel Path

Standard ping output is not enough evidence. The actual storage path needs to be proven.

5. Do Not Stop at “The LUN Is Visible”

Device visibility and datastore usability are not the same thing. Mount, path state, and test-VM validation all still matter.

First 15-Minute Checklist

The software iSCSI adapter is enabled and the IQN was recorded
The storage array confirms the correct IQN and ACL authorization
Discovery IPs and target details were reviewed carefully
The iSCSI vmkernel path and any required port binding were validated
vmkping -I <vmk#> confirmed target reachability
The correct LUNs appeared after rescan
Datastore creation or mount completed as expected
A test VM confirmed basic storage access

Next Step with LeonX

The biggest iSCSI setup mistake is treating network, identity, and storage authorization as separate concerns. LeonX helps teams define iSCSI discovery standards, vmkernel design, multipathing patterns, and datastore governance as one coherent operating model.

Related pages:

Frequently Asked Questions

What is the first critical step in VMware iSCSI datastore setup?

The first critical step is enabling the software iSCSI adapter and confirming that the host IQN matches the authorization configured on the storage array.

What should be checked first if the iSCSI target is not visible?

Broadcom KB 312779 says the first places to check are target IP, target IQN, ACL authorization, and CHAP settings.

When is port binding required?

Port binding is required when you design iSCSI multipathing with multiple vmkernel interfaces. Broadcom KB 429518 makes this explicit.

Is it a problem to leave Management service on the same vmkernel?

Yes. Broadcom KB 421153 shows that vmkernel ports used for iSCSI port binding become an unsupported design if Management service is also enabled.

Why can iSCSI datastores disappear after reinstalling ESXi?

Broadcom KB 409088 shows that the software iSCSI adapter IQN can change after reinstall, so storage authorization may still be pointing at the old identity.

Conclusion

VMware iSCSI datastore setup is not only about adding a target. Discovery, networking, identity, and multipathing all have to align. In the November 24, 2025 context, the safe approach is to enable the software iSCSI adapter correctly, validate IQN and ACL matching, prove the real vmkernel storage path, and apply port binding only in the supported model.

Sources

Share this article

Facebook

Twitter