<iScsiDiscoveryListInterfaces value="1"/>

robnicholson · Tue Jul 22, 2014 2:36 pm

This catches me out every time even though it's documented on our intranet. Pulling hair out trying to get iSCSI MPIO working in the lab until I remembered that in v6, you had to edit the configuration file to uncomment this line:



Stop & start the service and voila, you see all the network interfaces on the SAN server when connecting via iSCSI initiator using multi-path.

So a couple of questions:

Firstly, is there any reason this setting isn't uncommented by default? It appears to be the norm?

Secondly, can we please have an option during installation to configure this so one doesn't forget.

Thirdly, shouldn't you be able to configure if on the management console?

Cheers, Rob.

robnicholson · Tue Jul 22, 2014 3:23 pm

Tut tut - the installation of build 6884 overwrote this change! That really has to be classed as a bug. Upgrade to a new version should not simply overwrite the CFG file! And if it has to, it should at least warn you.

That's a recipe for disaster. Simple upgrade and bang - nothing works afterwards as MPIO is effectively disabled?

Cheers, Rob.

Wed Jul 23, 2014 5:01 pm

We`ll try to reproduce it in our test lab and I`ll get back to you with something after.

robnicholson · Mon Sep 22, 2014 3:50 pm

I've just upgraded to build 7185 from 6884 and this bug is still present, i.e. after upgrade the CFG file changed from:

<iScsiDiscoveryListInterfaces value="1"/>

to:



Now interestingly, the existing iSCSI initiators have reconnected cleanly after the upgrade so maybe this setting is only when setting up new storage? So whilst the existing iSCSI consumers have continued to work, I'm guessing that if I tried to set-up a new iSCSI initiator, that I'd have trouble?

So question, in layman's terms, what does this setting actually do???

Cheers, Rob.

Wed Sep 24, 2014 1:46 pm

1. The fix will be included in the next minor update
2. This string is commented to prevent ESX failure. MPIO will fail after node reboot. Basically it allows StarWind to give away the client initiator all the IPs that its host OS has.

Tue Sep 30, 2014 8:04 am

robnicholson wrote:I've just upgraded to build 7185 from 6884 and this bug is still present, i.e. after upgrade the CFG file changed from:

<iScsiDiscoveryListInterfaces value="1"/>

to:



Now interestingly, the existing iSCSI initiators have reconnected cleanly after the upgrade so maybe this setting is only when setting up new storage? So whilst the existing iSCSI consumers have continued to work, I'm guessing that if I tried to set-up a new iSCSI initiator, that I'd have trouble?

So question, in layman's terms, what does this setting actually do???

Cheers, Rob.

After update it should be:

<options>
…

…
<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 ?

robnicholson · Tue Oct 07, 2014 11:13 am

Hi Bodan,

You are indeed correct. It's not at the end though - the uncommented line is at line 92 but there are TWO uncommented lines at line 105 & 106:

<LocalizationDir value="Localizations"/>
<iScsiDiscoveryListInterfaces value="1"/>
<iScsiDiscoveryListInterfaces value="1"/>

The CFG file itself is 430 lines long.

So the bug is slightly fixed but having the same configuration setting three times in the CFG file is going to confuse people.

I've done enough with XML manipulation APIs to know that whilst it's more complicated, it's not impossible for the upgrade program to edit/modify the CFG file without rewriting it and fudging entries back in. Should not the process be?

Change request requires the addition of a new configuration setting in the CFG file (let's call it WindowBackground)
Two jobs are created for this: the first to implement the new setting in StarWind itself. The second to implement the change in the upgrade program
The upgrade program reads the XML file into an in-memory tree structure
It looks for the WindowBackground setting
If it's not there, it adds a new node into the XML tree. If it is there, it's value might be tweaked
The XML tree structure is written back to the CFG file

Personally, unless there is a compelling reason that having this setting off, it should be enabled by default so the upgrade program should:

If there is a commented out iScsiDiscoveryListInterfaces setting, then uncomment it and enable it
If there is an uncommented out setting, leave it it alone

Cheers, Rob.

robnicholson · Tue Oct 07, 2014 11:15 am

BTW - whatever the current system does, it's confusing as it's separated the setting from the comment:

 HERE IS THE COMMENT
 THIS DOES NOTHING










<LocalizationDir value="Localizations"/>
<iScsiDiscoveryListInterfaces value="1"/> BUT HERE IS THE VALUE
<iScsiDiscoveryListInterfaces value="1"/> OR IS IT THIS ONE?

Cheers, Rob.

Thu Oct 09, 2014 4:32 pm

HERE IS THE COMMENT
 THIS DOES NOTHING

AS you may know, the commented values and configurations are not taking into acount.

Having two identical strings in the config (below) is most likely the result of the fact that in the config file, which already had a string of <iScsiDiscoveryListInterfaces value = "1" /> uncommented again comment line with this value.

Code: Select all

<iScsiDiscoveryListInterfaces value="1"/> [b]BUT HERE IS THE VALUE[/b]
<iScsiDiscoveryListInterfaces value="1"/> [b]OR IS IT THIS ONE?[/b]

During the transfer settings to a new configuration Updater takes all rows with variable, and folds them into the section after the comment. For example, before an update it ooked like:

Code: Select all

<!-- Allow listing of interfaces in response to SendTargets=All --> 
 <iScsiDiscoveryListInterfaces value="1"/> 
<!--Force set of default parameters for iSCSI sessions-->
<!--<iScsiInitialR2T value="0"/>-->
<!--<iScsiImmediateData value="1"/>-->
<!--<iScsiDefaultTime2Wait value="0"/>-->
<!--<iScsiFirstBurstLength value="65536"/>-->
<!--<iScsiMaxBurstLength value="262144"/>-->
<!--<iScsiMaxReceiveDataSegmentLength value="65536"/>-->
<!-- <iScsiStrictProtocolChecking value="yes"/> -->
<!--<CmdExecTimeWarningLimitInMs value="0"/> -->
<iScsiDiscoveryListInterfaces value="1"/>

And after update it became:

Code: Select all

<!-- Allow listing of interfaces in response to SendTargets=All --> 
<!-- <iScsiDiscoveryListInterfaces value="1"/> --> 
<!--Force set of default parameters for iSCSI sessions-->
<!--<iScsiInitialR2T value="0"/>-->
<!--<iScsiImmediateData value="1"/>-->
<!--<iScsiDefaultTime2Wait value="0"/>-->
<!--<iScsiFirstBurstLength value="65536"/>-->
<!--<iScsiMaxBurstLength value="262144"/>-->
<!--<iScsiMaxReceiveDataSegmentLength value="65536"/>-->
<!-- <iScsiStrictProtocolChecking value="yes"/> -->
<!--<CmdExecTimeWarningLimitInMs value="0"/> -->
<iScsiDiscoveryListInterfaces value="1"/> 
<iScsiDiscoveryListInterfaces value="1"/>

As you can see a comment recovered from the new config, and two rows with the value of the old config was moved and placed side by side.

To summarize this:

- Before uncommenting it is better to doublechecck that section doesn`t contain this parameter. It looks like it was presented in your case.
- Right now it is better to remove the redundant string
- Values that are in  not affecting a thing
- In future releases we are planning to add ability to modify this setting into the GUI.

I hope this makes sense.