scsi-target-utils iSCSI Targets not displaying right

[JonWeatherhead]

I plan on creating several iSCSI datastores to share out the local disks of my ESXi 3.5 hosts. But when I add a second iSCSI target I get some funky results. Can anyone explain this and possible tell me what I'm doing wrong here? Please see the attached picture for reference as I walk through each step I took.

Step 1: I added the first iscsi target by adding the IP and port to the "Send Targets" for vmhba33, did the requested rescan, and I see the 235.99GB LUN as expected.

Step 2: Now i go back and add another "Send Target" to vmhba33 pointing to a second iscsi target ad a different IP. Then I do the requisite rescan. I see Target 1 gets added with the correct iSCSI Name... but wait, that LUN should be 400GB. And the Canonical Path is showing the path to my first iscsi LUN. I would think the Canonical Path should be vmhba33:1:1 (not vmhba33:0:1).

Step 3: If all else fails do a rescan right? But no, that only complicates things by adding another listing for the same array controllers that are already showing up way too often.

Can anyone explain why I'm not seeing the actual second iSCSI LUN? By the way, if I remove them all and start over by adding the 400GB iSCSI Target first, I get the same results but this time I see the 400GB LUN and not the 235.99GB LUN. Oh, and another thing, I also have some iSCSI LUNs running from iSCSI Enterprise Target (EIT) targets on my older esx hosts... they get added in with incremented Canonical Paths as one would expect.

[Jackobli]

I don't see why different IP are necessairy, but that should not be the problem.

I remember to read about similar problems, but I am not finding any posts, wrong keywords in my mind

What is "serving" this targets?

[JonWeatherhead]

I am using two different IPs because these are two different iscsi sources. There are multiple hosts each with their own VM that is serving its respective iscsi LUN, hence multiple IPs.

[Jackobli]

If there are two separate systems serving the targets, I am lost. I think I once read about problems with linux iscsi targets and their globally unique name or something similar to this.

[JonWeatherhead]

This acts very similar to what use to happen when using iSCSI Enterprise Target (IET) as the target. I don't know how to dig into the actual cause, but the symptoms are very similar. With IET the problem was that is passes space (0x20) values as the ScsiSN. If multiple targets are added that all have the same serial number, they get interpreted into various paths to the same target. Thats why with IET you are now suppose to define a unique ScsiSN in the ietd.conf file. I didn't look for anything similar when we were tying to use (tgt) so it might be there... But I never saw anything mentioned about this online anywhere.

I ended up rebuilding my target using (IET) instead. Ran into one sneaky problem though. When I defined the ScsiSN I made it "vis1-iscsi01-lun0". This led to a 3 hour goose chase trying to figue out why the target would show up by running the "vmkiscsi-tool -T vmhba33" command, while not showing up in the GUI. My name was too long. Changing it to "iscsi01-lun0" resolved the issue.

It would be nice if the README.vmware file found in the installation directory of iscsitarget-1.4.19 actually mentioned the length restriction.

Anyway, switching to IET solved my problem... guess I took the easy way out.

[jeff_stelzner]

I am using tgtd / tgtadm under CentOS 5.4 with several datastores, both VM-based and physical boxes.

I was able to setup 1 storage system with 1 target and 2 LUNs and it worked fine .

The problem I have is when I try to connect 1 ESXi 4.x host to multiple targets, each with 1 LUN :

/usr/sbin/tgtadm --lld iscsi --op new --mode target --tid=1 --targetname iqn.whatever:target16

/usr/sbin/tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/sdb

/usr/sbin/tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address=aa.bb.cc.dd/ee

In that case, ESXi will only connect to 1 target - If I specify multiple targets for autodiscovery, it seems to randomly pick 1 and only 1.

At this point my thought is that perhaps the LUN IDs need to be globally-unique.

Obviously the targetname needs to be unique for each storage appliance.

But I'm thinking that the --tid also needs to be globally-unique.

I have not yet tested it out, will let you know for historical interest .

[jeff_stelzner]

This appears to generate globally-unique SCSI SNs for both controller and LUN:

Using --tid=1 we get:

LUN: 0

Type: controller

SCSI ID: IET 00010000

SCSI SN: beaf10

LUN: 1

Type: disk

SCSI ID: IET 00010001

SCSI SN: beaf11

and these are the same on every iscsi server configured with --tid=1.

But if I specify --tid=11 we instead get :

LUN: 0

Type: controller

SCSI ID: IET 000b0000

SCSI SN: beaf110

LUN: 1

Type: disk

SCSI ID: IET 000b0001

SCSI SN: beaf111

LUN: 2

Type: disk

SCSI ID: IET 000b0002

SCSI SN: beaf112

So I assume that we need a unique tid on each box, whether it is serving 1 or multiple LUNs.

This also assumes that the SCSI SN displayed by tgtadm is in fact presented correctly to initiators .