New HA targets is using MS ISCSI Initiator

[lohelle]

All new (and existing) HA-targets is using MS ISCSI Initiator (v 5.
How do I force using the "new" sync method?
When restarting a node it takes several minutes to build all the sync-channel sessions.

On the primary node the ISCSI Initiator service is not even running, on node 2 I get one target (with 3 or 5 sessions) for every Starwind target.

I can bring down one of the targets, but I would prefer not to have to do a full sync.

Starwind 5.8.1889, Windows Server 2008 R2

[anton (staff)]

It's internal method we use. It's not dependant on what type of initiator you use to connect to target itself. What selected now in target properties?

All new (and existing) HA-targets is using MS ISCSI Initiator (v 5.
How do I force using the "new" sync method?
When restarting a node it takes several minutes to build all the sync-channel sessions.

On the primary node the ISCSI Initiator service is not even running, on node 2 I get one target (with 3 or 5 sessions) for every Starwind target.

I can bring down one of the targets, but I would prefer not to have to do a full sync.

Starwind 5.8.1889, Windows Server 2008 R2

[lohelle]

I stopped node 2, stopped and disabled MS ISCSI Initiator and started Starwind.
No sync!

Node 1 made the connections to Node 2, but no connections from Node 2 to Node 1.

Is there a way to force the use of the internal one?

If I delete the targets on node 2 and use the "switch to new HA partner" opton, will I need to do a full sync, or will a fast sync be possible? This is production storage, so I would prefer to fix without full sync or downtime.

[lohelle]

Fixed it on my own. Installed a clean install Starwind instance on my laptop and compared the config files.

I was missing a parameter in starwind.cfg

<plugin module="HAImage.dll">
<symlink value="HAImage"/>
<type value="HA Image"/>
<transport value="internal"/>
<imagedir path="*" flags="cmdfv" alias="My Computer" extensions="img"/></plugin>

Sync starts after a few seconds now.

The default value is auto btw. I used the internal value to be sure this was used. Did not test with auto.

[Anatoly (staff)]

I`m glad that everything is fixed now:)

Feel free to contact us if you`ll have such need!

[lohelle]

You might want to include a fix for this. Main reason was that I installed a newer version of Starwind on a new node and replaced it with an older version's config-file.
But I did run at least one upgrade from 5.8.x to 5.8.x, so maybe a check included when running upgrade? Or maybe default to "internal method" when missing entry in starwind.conf

[Anatoly (staff)]

We definitely will! Thank you for your input!

[WardA]

Reading this thread made me wonder if the same was happening with our storage. We have 2 sets of 2 servers running in HA, recently updated to v5.8.

On HA SAN A, both nodes have the following in their config, and no connections showing in MS iSCSI initiator in Windows:

<plugin module="HAImage.dll">
<symlink value="HAImage"/>
<type value="HA Image"/>
<imagedir path="*" flags="cmdfv" alias="My Computer" extensions="img"/>
<transport value="system"/>
</plugin>

On HA SAN B, both nodes have the following in their config, and lots of connections showing in MS iSCSI initiator in Windows:

<plugin module="HAImage.dll">
<symlink value="HAImage"/>
<type value="HA Image"/>
<imagedir path="*" flags="cmdfv" alias="My Computer" extensions="img"/>
</plugin>

I'm quite confused - both sets are running fine, all in sync etc, but obviously we'd like to be using the new internal sync method for both. So it looks like for HA SAN B, it is still using MS iSCSI for transport.

The thing that is even more confusing is the setting on HA SAN A where transport value="system". In the config file, it says that the values can only be:

"msinitiator" - system transport,
"internal" - plugin internal transport
"auto" - automatic transport selection

What does system mean, and how did it get there?

[lohelle]

Actually, I think my node had system as value also.

I shut down Starwind, changed to internal, shut down MS Iscsi Initiator (just to be sure it was not used) and started Starwind again. Sync started MUCH MUCH faster.

[WardA]

Hmm, OK, that makes me feel slightly better, hehe.

So we have HA SAN A with "system" set, and HA SAN B with nothing set at all, despite the fact it was upgraded from 5.7 to 5.8, without any copy/pasting of configs. Intriguing!

When you set yours from "system" to "internal", did you make the change on one node only, and when you brought it up, the syncing was working properly on both? Did you change the second node also?

[lohelle]

I did one node, then the other. It seems that it is not required that the nodes use the same type.

One of my nodes actually USED the internal method, the other used MS Iscsi. You can stop one of the nodes, change the config and start it again. In my case the connections went up VERY fast. Just look at the connections for the targets on the other node. I stopped MS Iscsi Initiator before I startet Starwind again, but I guess that is not required.

[WardA]

Cool. I'll try that on the HA Set that has "system" in there, and if that works, I'll try it on the set which has no transport key at all - provided no one from StarWind says I shouldn't!

Sadly, we have tons of VMs running from the storage, so I will need to do this OOH in case some horribleness ensues

[lohelle]

do not remove the key. change it to internal or auto.

[WardA]

do not remove the key. change it to internal or auto.

Sure, I will do that. What I meant was that we have 2 sets of HA nodes, A and B, and on the two nodes in HA SAN B, there is in fact no key for transport at all!

[Anatoly (staff)]

Sure, I will do that. What I meant was that we have 2 sets of HA nodes, A and B, and on the two nodes in HA SAN B, there is in fact no key for transport at all!

Dear WardA, would you kindly update us about your progress?

Thank you