The use of dynamic discovery (send targets) is a convenient way to present iSCSI storage to a vSphere host. The iSCSI array will report all of the targets available and masked to the initiator, saving administrators the headache of having to manually add all of the necessary IQNs.

In situations where the array is hosting multiple targets for various needs – such as for backups, users, or other workloads – the use of dynamic discovery can carry some caveats. Let’s walk through a simple example.

Imagine your ESXi host has two unique networks defined: one for host management (1.1.1.0/24) and another for iSCSI storage (3.3.3.0/24). You’ve created a vmkernel interface for Management and another pair for iSCSI using vmk binding. Additionally, there’s an array configured for iSCSI that you’re connecting to that also uses the management and vSphere networks. I’ve used a NetApp IQN in my example, but the specific vendor isn’t important.

In the example above, the ESXi host will see IQNs listed for the Management and vSphere VIFs. Because it has a direct network connection to the Management subnet, iSCSI traffic may end up traversing vmk0 (Management) and not use vmk2 or vmk3 (iSCSI) at all. This can happen even if you use vmk binding for iSCSI on the ESXi host.

It can be difficult to see this happen, although the use of esxtop can help flesh out which vmk’s are sending and receiving traffic.

Workaround

In this case, I would still use dynamic discovery (send targets) to discover all of the array’s targets, but then delete the dynamic discovery IP and remove any unwanted IQNs from the static discovery list use static targets (thanks to Patrick for finding the caveat behind removing send targets). Or, if you’re looking to script the process, pull a list of the correct IQNs from your target array and use a scripting language, such as PowerCLI, to configure the iSCSI adapter on the ESXi host.