StarWind Software

Still testing Starwind v6. Has anyone else noticed that ESXi 5.1 build 799733, doesnt interpret the ALUA preferencing correctly when using round robin with multipaths ? Our older hosts running ESX 5.0 or ESX 4.1 appear to work fine. I took a couple of screenshots to illustrate.

This is build 799733, and these are not the correct preference paths, it should be node 2. this hypervisor always defaults to node 1.
ESX 5.0 when seeing the same paths gets it correct.
I lodged a support ticket with vmware. Anyone know if there is a fix, or if I have missed something obvious.

Sorry missed from your post - do you run the same version (and build number) of StarWind everywhere?

anton (staff) wrote:Sorry missed from your post - do you run the same version (and build number) of StarWind everywhere?

Hey anton, yes we have two nodes running 4 HA disks on our storage network running v6 Build 20120927. first two HA disks have alua preference to node 1, second two disks are preferenced to node 2. esxi 5 and under recognises the correct round robin pathing but I have tried multiple esxi 5.1 hosts, and they always prefer node 1. I figure it must be a vmware bug, but it definetly doesnt work with vmware 5.1. I have lodged a support ticket with vmware.

Kind of strange... Please provide us with a feedback from VMware and if they will choose "fingerpointing route" we'll take a closer look @ this issue.

jimbyau wrote:

anton (staff) wrote:Sorry missed from your post - do you run the same version (and build number) of StarWind everywhere?

Hey anton, yes we have two nodes running 4 HA disks on our storage network running v6 Build 20120927. first two HA disks have alua preference to node 1, second two disks are preferenced to node 2. esxi 5 and under recognises the correct round robin pathing but I have tried multiple esxi 5.1 hosts, and they always prefer node 1. I figure it must be a vmware bug, but it definetly doesnt work with vmware 5.1. I have lodged a support ticket with vmware.

http://kb.vmware.com/selfservice/micros ... Id=1022030
http://blogs.vmware.com/vsphere/2012/02 ... vices.html

Could you please show the output of
esxcli storage nmp device list -d <device>
commands for both cases?

Bohdan (staff) wrote:
Could you please show the output of
esxcli storage nmp device list -d <device>
commands for both cases?

Sure... Let me know what you think.

ESXi 5.1 Host, NOT Correctly Preferencing Path to Node 2:

eui.a1dc60296c8bc6eb
Device Display Name: ROCKET iSCSI Disk (eui.a1dc60296c8bc6eb)
Storage Array Type: VMW_SATP_ALUA
Storage Array Type Device Config: {implicit_support=on;explicit_support=off; explicit_allow=on;alua_followover=on;{TPG_id=1,TPG_state=ANO}{TPG_id=2,TPG_state=AO}}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=2: NumIOsPending=0,numBytesPending=0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba4:C0:T6:L0, vmhba3:C0:T6:L0
Is Local SAS Device: false
Is Boot USB Device: false

ESXi 5.0 Host, Correctly Preferencing Path to Node 2:

eui.a1dc60296c8bc6eb
Device Display Name: ROCKET iSCSI Disk (eui.a1dc60296c8bc6eb)
Storage Array Type: VMW_SATP_ALUA
Storage Array Type Device Config: {implicit_support=on;explicit_support=off; explicit_allow=on;alua_followover=on;{TPG_id=2,TPG_state=AO}{TPG_id=1,TPG_state=ANO}}
Path Selection Policy: VMW_PSP_RR
Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=0: NumIOsPending=4,numBytesPending=20480}
Path Selection Policy Device Custom Config:
Working Paths: vmhba4:C0:T12:L0, vmhba3:C0:T13:L0

VMware support acknowledge there is a strange issue with the ALUA in ESXi 5.1 with Starwind 6 but because starwind software has not been certified with Vmware 5.x, there is nothing they can do, and wont even escalate it to the engineering team. Bottom line is that ALUA with ESXi 5.1 and Starwind 6 does not work. If you have some contacts with VMware to add this to the buglist, then that would be good as we might get a fix next release, otherwise were all stuck accessing a single node starwind san with no load balancing.

Heres the support synopsis.

VMware Support Request 12248547011

Issue :ESXi 5.1 build 799733 does not correctly use ALUA to detect the correct path preference when using the round-robin multiple path I/O option. However previous versions such as ESXi 5 build 469512 and ESX 4.1 348481 worked fine on the exact same targets to detect the correct paths when using round-robin.

ESX 5.1 799733 insists on only using the same target nodes regardless of the ALUA settings on the SAN.

Checked the VMkernel Logs about the same and got the same information.

Checked the Compatibility and found that the Starwind Rocket ISCSi is not supported for 5.x

Partner Name Model Array Type
StarWind Software Inc. Enterprise HA iSCSI

Supported Releases ESX : 4.1 U3 4.1 U2 4.1 U1 4.1

Update: we have identified the problems reason and hopefully we will update the build on our website.

Thank you

Anatoly (staff) wrote:Update: we have identified the problems reason and hopefully we will update the build on our website.

Thank you

Do you know which build it will be fixed in? Is there a way to download the different builds? There seems to be only one trial link.

Already fixed (well, not the right word as it's VMware who had changed some things so let's say - workarounded). Few more tests and we'll contact you off-forum to verify how it works for you.

jimbyau wrote:

Anatoly (staff) wrote:Update: we have identified the problems reason and hopefully we will update the build on our website.

Thank you

Do you know which build it will be fixed in? Is there a way to download the different builds? There seems to be only one trial link.

anton (staff) wrote:Already fixed (well, not the right word as it's VMware who had changed some things so let's say - workarounded). Few more tests and we'll contact you off-forum to verify how it works for you.

So is this work around version available yet? What build is currently available for download and where can I get it?

Yes, everything is done so far. Please apply support@ for a private build link.

jimbyau wrote:

anton (staff) wrote:Already fixed (well, not the right word as it's VMware who had changed some things so let's say - workarounded). Few more tests and we'll contact you off-forum to verify how it works for you.

So is this work around version available yet? What build is currently available for download and where can I get it?