vSAN iSCSI Target Works for a Guest but Not an ESXi Host: Check the Initiator

A vSAN cluster serves an iSCSI target. A Windows or Linux guest connects to it and sees its disk. An ESXi host, set up with the same target in its software iSCSI adapter, shows no device.

This is easy to read as a network, CHAP or LUN masking problem. Check one thing first: what kind of initiator is asking.

Broadcom states the limit directly in KB 404900:

• Symptom: the vSAN iSCSI target "is correctly configured and has been added to the ESXi host's software iSCSI adapter as an initiator. However, the associated iSCSI devices are not appearing under the storage devices list on the host."
• Cause: "vSAN iSCSI target service does not support other vSphere or ESXi clients or initiators, third-party hypervisors, or migrations using raw device mapping (RDMs)."

The vSAN 8.0 administration guide says the same thing in the same words (Using the vSAN iSCSI Target Service).

This article shows how to place the initiator against that limit before anyone starts network or storage changes. It is source research only. Nothing in it was run. All names are fictional.

Who the target service is for

Two consequences follow:

• Discovery is not evidence of support. The KB's symptom starts after the ESXi adapter is configured, and it still ends with no device. Separately, the absence of an initiator restriction (no individual initiator and no initiator group defined on the target) only means the target does not restrict by IQN. It does not show that the network path works, that discovery succeeds, or that CHAP authentication passes. Those are separate conditions, recorded from what you observe.
• A working guest does not show the target is healthy for ESXi. KB 404900's title describes the target as "Accessible by Resident VMs". The difference between the guest and the host is the initiator type, and the ESXi initiator is the unsupported one.

This guide does not say which guest operating systems or cluster architectures are supported. Check those against the vSAN guide for your release.

Draw the boundary first

Write down three things for the failing case.

If the initiator is an ESXi host, whether inside the same cluster or in another vSphere environment, the use falls under the documented exclusion. The same applies if the intended consumer is an ESXi datastore or an RDM migration. Stop there: the finding is that this use is outside Broadcom's support boundary, and the design decision goes on for separate review. That finding does not rule out a coincident network, authentication or target problem. It means no experiment is run to make the unsupported use work.

Read-only checks

Use these only to complete the record. They change nothing.

1. Target and initiator groups. On the cluster, open Configure. Under vSAN, select iSCSI Target Service (Create a vSAN iSCSI Initiator Group, 8.0). Record the target IQN, its LUNs, any individual initiators assigned to the target, and the Initiator Groups tab members. Do not click Add. Broadcom warns that once an initiator group is created on a target, initiators outside it lose their existing connections.
2. Target object health. On the cluster, open Monitor > Virtual Objects. iSCSI targets are listed there, and View Placement Details shows where the target's components sit and whether any have failed (Monitor vSAN iSCSI Target Service, 8.0). A guest that reads the LUN, together with healthy components, is recorded as observed. It does not exclude other faults on the ESXi side or in other target functions.
3. Initiator identity. Record the IQN of the working guest initiator and of the ESXi software iSCSI adapter. Two different IQNs is what you would expect. What matters is that one of them belongs to an ESXi host.

Worked example (fictional)

Reading it:

• Both initiators were observed to discover the target. No individual initiator or initiator group is recorded, so the target does not restrict by IQN. That observation says nothing about support.
• The target object's components show healthy, and the guest reads the LUN. Neither rules out another fault.
• The failing side is an ESXi host's software iSCSI adapter, which the target service does not support (KB 404900; vSAN 8.0 guide; KB 326884).

Finding: the intended use is outside the documented support boundary. That stands whether or not some other fault also exists. Network, CHAP or target changes, re-adding the target or formatting the device are not run as experiments to make it work.

What to hand on: the record, the KB 404900 cause line, and the intended use of esx-b07. Broadcom's direction for ESXi storage, backup storage or non-VMware use is a different iSCSI target, such as a third-party SAN or NAS. Choosing and moving to that storage is a separate design decision.

Troubleshooting

Acceptance checks

1. The target, the initiator and the intended consumer are recorded for the failing case.
2. The initiator type is named: guest operating system, physical host, ESXi host or another hypervisor.
3. If it is an ESXi host, a third-party hypervisor or an RDM migration, the finding is "outside the documented support boundary", with KB 404900 and the vSAN 8.0 guide cited. The record does not claim other faults are ruled out.
4. If it is not an excluded initiator type, the case is passed on as an ordinary iSCSI investigation, without this article's finding.
5. Access restriction (individual initiators and groups), discovery, CHAP and network reachability are recorded as separate items, each from observation.
6. No target, LUN, initiator group, adapter or datastore was changed during the check.

Risk notes

• Formatting or remapping a device that should not be there is the real danger. If an unsupported path somehow presents a device, it is still unsupported. Do not put a datastore on it.
• Creating an initiator group drops existing non-member connections, including working guests, until they are added.
• Re-pointing a workload's storage is a migration, not a fix. Plan it separately.
• Do not assume every vSAN architecture behaves the same. This article does not claim the service is available, or behaves identically, on every architecture.

These are source-documented limits. Expert review and a lab check are still needed before any storage design change.

Learning notes

• The vSAN iSCSI target service is for hosts and physical workloads outside the vSAN cluster. ESXi and other vSphere initiators are excluded. Check guest support against the guide for your release.
• When an ESXi host discovers the target but shows no device, that matches the documented exclusion. It is a support-boundary finding, not proof that nothing else is wrong.
• With no individual initiator and no initiator group defined, the target does not restrict by IQN. Network path, discovery and CHAP are still separate, and none of them proves support.
• Broadcom's alternative for ESXi, backup or non-VMware block storage is a separate SAN or NAS target.

References

Related articles

• Design and validate vSAN storage policies
• Diagnose VMware vSAN storage latency