Target name enumeration bug ?

[dannyboy1121]

9.2.0.1 - Shigawire (revision 943)

1 - Set up a volume based lun and and associated target named LUN1
2 - Using iscsiadm from linux host, run discovery against N4F box - LUN1 displayed
3 - Repeat the process and call the target name anything alphabetically / numerically preceding the original target name (e.g. AAA ---> LUN0)
4 - Using iscsiadm tools from linux host, run a discovery against the N4F box - targets all returned as LUN1 (i.e. now 2 x iSCSI LUNs - both LUN1 .. NOT LUN1 and AAA).
5 - Change the target name on N4F box for second LUN to anything after LUN1 (i.e. LUN2 ----> ZZZ) and apply
6 - On linux host, run discovery again. Now LUNs are properly enumerated with their correct names.

Is this a known bug? I can't be the first to find this.

[apollo567]

Did you test it with the latest version of N4F ?

[dannyboy1121]

Not yet. I'll upgrade and test this weekend.

[DataX]

I'm also seeing this issue with the latest N4F, 9.3.0.2 rev1213.

Not sure if this is a N4F issue or something specific to istgt, however if an additional target is alphabetically listed before the first target created, the iSCSI command returned gives both targets the same name.

I verified this with WireShark. The first target I created was named 'esx01' and in both cases the SendTargets=All command is sent. When the 2nd target is named 'esx02', the iSCSI response is as expected and both targets are listed. When I change the target name to 'esx00' (or anything that would be listed before 'esx01'), the iSCSI response still responds with two targets, but lists them both as 'esx01'.

[DataX]

So after hours of searching, troubleshooting and finally deciding to post, I find a solution 5 minutes later. Figures.

viewtopic.php?p=9892#p9892

I would absolutely agree with the poster and suggest the addition of a prompt to restart istgt after adding a new/non-alphabetical target.