Problem with Microsoft iSCSI initator

[Slingshotz]

This is driving me nuts so I'm hoping that someone here may have encountered this.

I have a three node setup and the Starwind clusters are replicating perfectly between all three with no issues. The problem is trying to connect the iSCSI targets with MPIO between two of the servers. I have 4 10Gig ports in each server dedicated to the sync and iSCSI data but they are interconnected to each other directly with cables instead of going though a switch.

This is my very current simplified configuration:

Server 1: iSCSI Data IP addresses 10.2.3.1 and 10.2.6.1
Server 3: iSCSI Data IP addresses 10.2.3.3 and 10.2.6.3
Server 2 can be ignored as it doesn't factor into the issue and all the sync IP addresses for Starwind are in a different subnet from the iSCSI.

Both server 1 and 3 have discovery target portals setup to look at each other as far as I can tell (ignore the 10.2.2.x and 10.2.4.x subnets as they are for server 2).

Capture.JPG (34.83 KiB) Viewed 16579 times

When I'm on server 3 and connecting to the iSCSI target located on server 1, I can assign 10.2.3.3 and 10.2.6.3 as the initator IPs and 10.2.3.1 and 10.2.6.1 as the target portal IPs like I'm supposed to.

Capture1.JPG (24.72 KiB) Viewed 16579 times

However, when I'm on server 1 and connecting to the iSCSI target located on server 3, I can only assign 10.2.3.1 as the initator IP and 10.2.3.3 as the target portal IP. I am unable to select the 10.2.6.3 as the target for 10.2.6.1.

Capture2.JPG (31.64 KiB) Viewed 16579 times

This doesn't seem to make any sense why it works one way and not the other. I have tried dumping the target portals and recreating them as well as ensuring the firewalls, etc are off. There's no CHAP permissions I'm using nor are there any deny access rights in Starwind on any server. If anyone has any ideas it would be greatly appreciated. I've been pulling my hair out for hours trying to figure this out.

[Anatoly (staff)]

Can you doublecheck if the string below in the starwind.cfg file is uncommented on both servers?

Code: Select all

      <!-- <iScsiDiscoveryListInterfaces value="1"/>-->

[Slingshotz]

Can you doublecheck if the string below in the starwind.cfg file is uncommented on both servers?

Code: Select all

      <!-- <iScsiDiscoveryListInterfaces value="1"/>-->

Yes it is uncommented on all servers. That's one of the first things I had to do when initially setting it up.

However, I just upgraded to the latest build and it reset the configuration like I expected. However, whenever I uncomment it out it seems to revert back after a few minutes for some odd reason. I have changed it numerous times and I can't find a pattern on why it reverts back.

[Anatoly (staff)]

Wow! That is weird, never seen it before. Did you restart Starwind service? Have you applied the changes using admin rights?

[Slingshotz]

I made all these changes, then rebooted each server and I'm making the changes with admin rights. For a test, I modified the cfg file on Friday night, checked that the changes were made on each server, restarted the services on each server, checked the cfg file again after restarting, and then left it alone over the weekend. When I came back today, two out of the three servers changed the cfg back. There was no maintenance, rebooting or anything else done to the servers over the weekend. It is very odd.

[robnicholson]

Yes it is uncommented on all servers. That's one of the first things I had to do when initially setting it up.

Heads up - any changes you make to the CFG file are lost during upgrade in v8... I'd probably suggest:

1. Make a copy of the CFG file
2. Upgrade StarWind
3. Wait until all nodes are synchronised
4. Shutdown StarWindService
5. Use WinMerge to compare the CFG files and merge any edits back (run as administrator)

Cheers, Rob.

[Slingshotz]

So it looks like my issue with the iSCSI targets was caused by another issue that I had opened with Starwind support. Anatoly confirmed that a bug exists if you manually edit the Replication node interfaces to add additional sync channels that it would disappear after a reboot. After manually modifying the .swdsk files by adding the missing the iSCSI sync channels, the sync channels are persistent after a reboot. Also the Microsoft iSCSI targets show up properly and I have the full list to choose from again.

[Anatoly (staff)]

Just got the heads up from R&D - after update to the latest version you should have two identical strings, but one will be commented and the other one - uncommented. Can you check that please?

[Bohdan (staff)]

After update it should be:

<options>
…
<!-- <iScsiDiscoveryListInterfaces value="1"/>-->
…
<LocalizationDir value="Localizations"/>
<iScsiDiscoveryListInterfaces value="1"/>
<DefaultStoragePoolPath value="My Computer\D\img\"/>
</options>

In other words the commented string is also presented in the cfg file, but the uncommented one is at the end of the "options" section.
Could you please check the StarWind.cfg file one more time ?

[claritytech]

Confirmed that this is a bug of some kind during the upgrade. After upgrade to 7354 we lost all the additional targets in the iSCSI initiator and found that this line had been commented. It was all working fine before the upgrade.

[Anatoly (staff)]

May I doublecheck if you have two identical strings as I asked in my previous question?