VMware ESXi Not Finding Any Devices

[bvandorf]

when trying to connect with VMware ESXi the ExecuteCommand where it is checking if lun >= m_disks.Count is returning the CheckCondition status code.

[TalAloni]

Which ESXi Version? What is your configuration? (How many disks have you added / what type) Could you provide a WireShark log?

[bvandorf]

ESXi 5.5 Just 1 target with a 1 standard Virtual Disk vhd. Wireshark Of ISCSI.zip

[TalAloni]

Looking at the WireShark log, I can see that the initiator (VMWare ESXi) is sending ReportLUNs, gets a list with a length of 8 bytes (with LUN 0 as a single LUN) and then it's sending Inquiry LUN to LUN 8 (instead of LUN 0).

I can't find anything wrong the responses the server is sending, I'm not sure where the problem lies. IIRC I have tested ESXi 5.1 in the past and there was no problem there.

[TalAloni]

Are you up to date on the latest ESXi 5.5 patch?

[bvandorf]

No, I don't have the latest patch I have build 1331820. but the strange thing is that it works perfectly with starwinds iscsi software and I am not familiar enough with iscsi protocol to know what is wrong exactly.

Here is the wireshark of the starwind iscsi. Wireshark Of ISCSI From Starwind.zip

[TalAloni]

Thanks, that WireShark log is very helpful, I see that their ReportLUNs response is padded with zeroes if the list is not long enough to match the requested allocation length, I can't find any documentation suggesting that's the correct behavior, but here is a test build imitating that: http://vm1.duckdns.org/Public/ISCSIConsole/iSCSI-Console-ESXi-Workaround.zip

A WireShark log of ESXi with the test build might be helpful.

[bvandorf]

Unfortunately, I tried the workaround exe you provided and it does the same thing. so I was looking at the Wireshark captures of this and the starwind capture and noticed that response to the report luns command every time there are tcp packets that get sent with the FIN flag but I am not sure why i just wonder if that has anything to do with it.

[TalAloni]

Could you provide a WireShark capture with the workaround? I don't think the issue is within the TCP layer.

[bvandorf]

Wireshark Of ISCSI Workaround.zip

[TalAloni]

it seems that not all packets are captured in the logs you sent, The first login session is the discovery session, during which the initiator gets the list of targets, Following that, and before the Report LUNs command is sent, there should be a Login to that specific target, which is missing from the packet capture. I usually use 'host 192.168.1.x and port 3260' to capture both sides of the communication with the iSCSI target server.

[bvandorf]

I have recaptured, the only filter I am using is on port 3260. Wireshark Of ISCSI Workaround 2.zip

[TalAloni]

Thanks, Your last WireShark log, while still incomplete for some reason, hinted that ESXi pings the target before sending the ReportLUNs command, and it uncovered a bug where the StatSN was not incremented after such ping response. I have committed a fix, please test this build which contains both the fix and the previous workaround (not sure yet if it's necessary): http://vm1.duckdns.org/Public/ISCSIConsole/iSCSI-Console-StatSN-Fix-And-Workaround.zip

[bvandorf]

This last StatSN fix is working great I have stopped and started and closed and restarted the exe multiple times and ESXi was able to successfully show the disks associated with the target every time, I am not sure if the padding is needed but will try without the padding if you want.

[TalAloni]

I'm glad to hear that! here is a build with just the StatSN fix without the padding workaround, please test and report back: http://vm1.duckdns.org/Public/ISCSIConsole/iSCSI-Console-StatSN-Fix.zip (this build is equivalent to the current master branch)

[bvandorf]

Yeah, it works just fine without the padding.

Thanks for all your help.

[TalAloni]

Great, I have released v1.4.7 which includes the StatSN fix, thanks for your help!