StarWind iSCSI SAN V5.3 Build 20100323

Thu Mar 25, 2010 10:03 am

Ladies and Gentlemen!

Here's the most recent beta version (excepted to grow to the RC and StarWind V5.3 after approve)

http://www.starwindsoftware.com/beta/bu ... 100323.exe

it's the same (renamed) link you've got by e-mails. Please give it a try and let us know.

Most critical change: we've got rid of StarPort BSODs on the nodes and crafted Hyper-V compatible
reservation re-acquire (after service was manually stopped).

Thank you!

Anton Kolomyeytsev

meatball15 · Sat Mar 27, 2010 5:31 pm

I was using the previous version (not sure the build number) with VMware VSphere 4 and was having lockups and PSOD. I just installed the latest verions 2010323 and those issues seemed to have gone away. I can create VMs on the iSCSI datastore without a problem. I'll update with any other issues I find. Thanks.

Sat Mar 27, 2010 8:33 pm

Wow! These are really good news! Please keep us updated. Thank you!

meatball15 wrote:I was using the previous version (not sure the build number) with VMware VSphere 4 and was having lockups and PSOD. I just installed the latest verions 2010323 and those issues seemed to have gone away. I can create VMs on the iSCSI datastore without a problem. I'll update with any other issues I find. Thanks.

Mon Mar 29, 2010 9:43 pm

OK, we've fixed one minor timeout issue with this build, have new one 20100329 as RC1 so far... Anybody interested could e-mail us support@starwindsoftware.com and we'd push official test welcome tomorrow. Thanks!

Martin Fluck · Fri Apr 09, 2010 8:36 am

Xen Sever 5.6 (Beta) Pools - does not re-connect to shared storage if StarWind server is rebooted.

I have been doing some testing with Hyper V R2 CSV and XenServer 5.6 Pools and so far all is good except that if the StarWind server is rebooted or drops network connection for any reason (for example the Hyper V host it is on needs a reboot) then the Xen Servers do not reconnect to their LUNs. Hyper V hosts reconnect no problem as soon as the LUNs are available again.

Now this could well be an issue with Xen Server 5.6 as it is still in beta but just thought I would mention it in case any one else has seen this behavior.

I will do some further testing with non beta XenServer and report back if the behaviour is the same.

cheers,

Martin

Fri Apr 09, 2010 9:20 am

Martin Fluck wrote:Xen Sever 5.6 (Beta) Pools - does not re-connect to shared storage if StarWind server is rebooted.

I have been doing some testing with Hyper V R2 CSV and XenServer 5.6 Pools and so far all is good except that if the StarWind server is rebooted or drops network connection for any reason (for example the Hyper V host it is on needs a reboot) then the Xen Servers do not reconnect to their LUNs. Hyper V hosts reconnect no problem as soon as the LUNs are available again.

Now this could well be an issue with Xen Server 5.6 as it is still in beta but just thought I would mention it in case any one else has seen this behavior.

I will do some further testing with non beta XenServer and report back if the behaviour is the same.

cheers,

Martin

Martin,
thanks for your feedback!
Yes, we know about this problem and our dev team is working on the fix.

Martin Fluck · Fri Apr 09, 2010 9:47 am

Hi Bohdan,

Also just remembered, you prob aware already, but found that in order to get the XenServer 5.6 servers to connect to the StarWind LUNs I have to set the default rule to allow access to all targets for all.
Once they connected to the Targets all ok to use the Access Rights and set the default rule back to deny all. Hyper V R2 non probs connecting at all with the default rule set to deny and Access Rights giving permission to the IQNs.

thanks,

Martin

Constantin (staff) · Fri Apr 09, 2010 10:12 am

To connect to targets using Xen with default policy "Deny all" you should also add IP of initiators or IQNs to ACL.

Fri Apr 09, 2010 10:36 am

Constantin is right.
In case of "Deny" default access policy you should add two allow rules for the both XenServers using either their IQNs or IP addresses.

Martin Fluck · Fri Apr 09, 2010 10:56 am

Hi Guys,

Yeah that is how I have it configured, there are ACL rules in place to allow both the XenServer IQNs and IPs, and as reported the ACL works ok and allows access through to the LUNs but only if the LUNs are already connected. If I reboot the XenServer with the deny all rule in place and the specific ACLs configured to allow access, the XenServers won't find their LUNs. Hyper V has no problem.

I will test this again now just to make sure this is the case and update shortly.

thanks,

Martin

Martin Fluck · Fri Apr 09, 2010 11:24 am

Quick update -

Just checked the ACL to confirm both IP and IQN for both pool servers are allowed access to the XenServer LUNs.

Default rule set to deny.

- reboot the XenServers and no reconnection to the LUNs
- Run Repair on Storage Repository - failed to connect to LUNs

set Default rule to Allow

- Run Repair again and Storage Repository connect ok.

set Default rule back to deny now servers have connected - access to Storage Repository remains ok.

thanks,

Martin

Fri Apr 09, 2010 11:34 am

Interesting...
Could you please zip and send me StarWind logs?

Martin Fluck · Mon Apr 12, 2010 7:47 am

Update - Issue was caused by incorrcet IQN in the ACL for the Xen Servers so not an issue with StarWind or Xen Server but rather my typing skills

Mon Apr 12, 2010 7:49 am

Martin,

thanks for your help!

7121ipbl · Mon Apr 12, 2010 10:02 pm

I have bee testing Starwind HA option with vSphere 4, since March 26. I have been able to fail the Starwind nodes and rebuild them without any issues so far. I have been running 2 x vSphere servers with 2 HA Starwind nodes with 1TB. I ran 8 virtual machines.

software versions.
----------------------
vCenter Server 4.0.0 Update 1 build 208111
ESX 4.0.0 Update 1 build 208167

HA starwind nodes.
Windows Server 2003 Standard Edition Service Pack 2, 2GB RAM

Starwind v5.3 Build 20100323
1TB hard drive, non raid.

Alex