iSCSI 127.0.0.1 not connected first on host reboot

[LudoEXEC]

Hello,
I am facing a problem with a Windows 2008R2 2 nodes Hyper-V cluster and Starwind v8. Each time I reboot one of the two nodes, the loopback is not set active first in the iSCSI connections. The initiator takes one of the two iSCSI backup networks and leave the other one and loopback on standby. I have to modify manually the MPIO settings and set 127.0.0.1 as active each time. I have not seen this behaviour on 2012R2 Hyper-V cluster with the same starwind version.
I have checked the starwind.cfg : iscsiDiscovery....is well uncommented.
Help is welcome.

regards

[Anatoly (staff)]

Have you made sure that you are using Round Robin?

[LudoEXEC]

You mean "not using" round-robin, no ?
MPIO load balance Policy is set as it should : Fail Over Only.

[Anatoly (staff)]

Right...

Well, first of all, that doesn`t look like the StarWind related problem. Is there any chance you can ask this question to MS tech support?

As for now maybe you could write some PoSh script that would set 127.0.0.1 address as the active path in initiator after the reboot.

[LudoEXEC]

[quote=
As for now maybe you could write some PoSh script that would set 127.0.0.1 address as the active path in initiator after the reboot.[/quote]

Thank you for that good idea !
Any quick examples / web links on how to do that kind of Powershell ?

Thanx Anatoly
Best regards

[Max (staff)]

Just did a quick search and it looks like there is no direct way to manage the active session through PowerShell.
As a workaround, I'll offer to do a script with the following logics:
127.0.0.1 target reconnecting triggers a disconnect of the partner target and then its reconnect.

But I would also consider updating the configuration to 2012 R2

[LudoEXEC]

Thanx very much !
Honnestly, are the two backup iSCSI networks (iSCSI Data1 and iSCSI Data 2) really necessary ?
Can I live with 127.0.0.1 on each hosts and the two 10Gbs Sync1 and Sync2 links for Starwind ?

regards

[Anatoly (staff)]

What will you do if StarWind service on the local host will go down for any reason then?

[Kayakero]

This is still happening with Windows Server 2016.
I know it does not seem a StarWind problem, but there's gotta be some logic or explanation as why Windows is changings Paths IDs on reboot.
I can't figure out its logic. Sometimes it seems it leaves all as it is, sometimes it seems changes active path on reboot.
A script using mpclaim.exe is a nightmare maybe some powershell script ? Any example ?

[Ivan (staff)]

Hello Kayakero,
Unfortunately, we did not find yet the way how to automate this process. The information about the disk path contains in the registry, WMI and can be managed from mpclaim.exe, but its still not clear how to bind loopback IP address with path IDs.
So at this point, I think the best way is to check the connections manually every time after restarting the server.
Please keep in mind Failover only MPIO policy recommended to use only with 1 GbE iSCSI channel. With 10 GbE iSCSI channel we recommend to use Round Robin, where this "issue" not present at all.

[Kayakero]

And what would happen if I set Round Robin (with subset) and somehow Starwind target reports the loopback path as optimized ?
Would that work? That would be ALUA.
That way windows would prefer the loopback even if that path comes up late.
I'm using just 1gb NIC, so I'm trying to avoid writing to the partner node (at least at iSCSI level, of course it needs to write to the partner thru Sync NIC underneath)

[Ivan (staff)]

Hello Kayakero,
Thanks for your reply!
I have tested Round Robin with subset (loopback are active, partner are standby) and after rebooting the server both connections become active.
Did you try to delay the iSCSI Initiator service as I suggest on this link: https://forums.starwindsoftware.com/vie ... 6&start=30 ?

[Kayakero]

I've seen your suggestion of delaying the starting of the initiator service, and I don't like much, it doesn't seem very clean.
Also I'm not 100% sure this problem is caused by the local target being up late as you suggest.
For example, I've turned off node 2, caused a hell of a lot of write activity in node1, then started node2, if that was the case, node 2 should take some time to sync, so active path on node2 will point to node 1 as local is catching up, but that didn't happened, it all stayed as it should in node 2, loopback path active, other node path standby.

Anyway, maybe I'm wrong, and what you say is really the cause of the changing of active path. I'm really confused with this stuff.

What I really like is a script (WMI or whatever) to set the loopback path as preferred. That is a cleaner solution.

[Ivan (staff)]

Hello Kayakero,
We will put this task in our roadmap.