Be careful of 3.1.3 upgrades to V class

[hdtvguy]

We upgraded our 7200 arrays to 3.1.3 without issue, but bot our V400 class arrays have serious issues. Both arrays hit similar issues, while the arrays stayed up the management access via network was lost. One came back but the arrays management processes are still not working properly. The other array we have been blind to for over 5 hours as HP tries to pull their heads out of their butts to figure out what is wrong. And as usually support is clueless and trying to get it escalated is even more frustrating. Funny 3.1.3 is a controlled release, meaning you need to get approval to do it, you would think they would have extra resources available since they are being cautious about doing it, but seems that is not the case. I have learned my lesson, no more initial releases of anything, 1 or 2 major service packs before I touch anything any more. We recently were burned by vmware 5.5U1 as well. These vendors bypass so much QA lately it is sad. And for 3par, boy do I have serious regrets about this not ready for prime time storage.

[hdtvguy]

Folks I want to warn you to stay away from 3.1.3. It has serious issues. We have been in a crippled state for 11 hours and basically are reverting back to 3.1.2. Through this process L3 discovered that there were developer notes in 3.1.3 for some of the exact issues we are having that were evidently ignored by QA. My suggestion is get to 3.1.2 MU3 and stay there or wait for 3.1.3 MU1 or skip 3.1.3 altogether. In 2 weeks we have had 2 major disruptions to our arrays due to poor code, QA or support. Clearly 3par can not scale to HP's size and HP has been unable to turn 3par into an Enterprise class organization.

[hdtvguy]

Latest update. Issue is a bug with RC ports, if you have your RCIP ports hard coded to a speed vs. auto do NOT do 3.1.3 until you change your RCIP ports to AUTO for speed. Evidently the developers know about this bug, but it fell through the cracks in QA and release.

[mugurs]

Could someone assume that if RC ports are not used than the entire upgrade process would be OK?
I'm also in the process for upgrading 2 x V800 to 3.1.3 and your post is by far not reassuring at all.

thanks,
mugurs

[hdtvguy]

I can not tell you about unused ports, but I would just set unused ports to AUTO, but I suepct they are that way if you did not change them as that is the default.

[hdtvguy]

OK so this bug impacts 3.1.3 on any array that has any network ports set to a fixed speed and not AUTO. Seems the Inform network driver has a bug that returns an invalid speed/status if the nics are a nic is not set to AUTO. So if you go 3.1.3 verify all your NIC settings in the array. I assume this means RC and Management ports.

[Richard Siemers]

"Controlled release" = Does that mean that you volunteered for it?




At least was your storage online and servicing hosts during the trouble shooting process, as in no hard outages?

Was the problem with all network ports, and your 7200 was just set to auto... or is the problem specific to the adapters used on the V400/V800?

[BryanW]

Hopefully they will patch this issue with the heartbleed patch.

[hdtvguy]

Heartbleed patch is out. This bug will not be patched until a future update. Best I can tell it impacts any array that uses Intel NICs on the nodes and he RC and Admin ports use Intel NICs so it can happen if any of the ports are set to a fixed speed. My 7200 and 7400 arrays were all set to Auto as they are fairly new. My V400 was set to 1gb becasue back in 3.1.1 days there was another network bug with some Cisco switches that casues the admin ports to flap if they re at Auto. Very shocking that in 201x 3par can not get a network drive for Intel that works right.

[apol]

How can you determine if all ports are set to the correct (=auto) setting?

shownet tells me that the cluster adress is set to auto.

We don't have any RCIP ports. But do I need tho check ports on the nodes or the sp as well?