7200 OS Upgrade to 3.2.2

[bajorgensen]

Hi.

I'd like to share some information I recently acquired from a HPE support case.

There is an internal document on Storeserve RECOS (recommended OS) that is nonpublic.
It was shared to me on a support case with internal links, so I wont share here.
This has several fiels:

- most recent
- monitored release
- default version
- N-1 version

As mammegutt mentions it lists 3.2.2 for 8k/20k and 3.2.1 for 7k/10k.
When I received it 3.2.1 EMU3 was default version, that might have changed during summer, as said.
Due HW enablement we are running 3.2.2 on several arrays, but unless you absolutely need it, stay on 3.2.1.
3.2.2 has been an absolute nightmare, and the VAAI offloading bug with data corruption in not entirely solved in 3.2.2 EMU2 (will be in MU3) but 3.2.1 MU5 has the complete fix.


Regarding self upgrades, there were added features to do this in a service processor release,
but just dont do it!

For the latest releases HPE has been running some rather huge pre upgrade scrips in order to awoid bugs and pitfalls in the ugprade process.
You pay for it, so let them do it, and have the proper people on the line in case things go south.

[Josh26]

For the latest releases HPE has been running some rather huge pre upgrade scrips in order to awoid bugs and pitfalls in the ugprade process.

And therein is specifically the problem I was referring to. These scripts aren't documented, you can't call support and ask for them (I've tried, they tell you it's intellectual property), but they are considered requirements on recent upgrades (despite never being referred to in release notes).

Effectively, regardless of what may have been planned at some point, this means you can't self-upgrade.

[rotorhead1]

3.2.2 is GA for 7k/10k and was GA for 7k/10k on day1 of release. If you need a feature in the 3.2.2 code on a 7k or 10k, simply stating that should be enough to get the upgrade scheduled and approved.

As an example, Remote copy is only supported between the same versions with an accepted transition state of 5 weeks. (Check page 18 for full list here http://h20564.www2.hpe.com/hpsc/doc/pub ... -c02660486 ).

If 3.2.2 wasn't supported on 7k, then you couldn't replicate between a 7k and a 8k system in a supported configuration which is just silly. Release notes for 3.2.2 also clearly states that 7k and 10k are supported.

If it 3.2.2 was GA for 7/10k then why would HPE state that it is not supported and not allow us to move forward. We have tried 3 different times to upgrade and denied each time.

Reading subsequent posts about 3.2.2, we are going to stay away from it......

[bajorgensen]

"If it 3.2.2 was GA for 7/10k then why would HPE state that it is not supported and not allow us to move forward. We have tried 3 different times to upgrade and denied each time. "

Maybe they are protecting you without admitting fault on the 3PAR OS?
Go to 3.2.1 MU5 and let the rest of the world battle it out with HPE and do the bug squishing.
We've been hit with some absolutely mind blowing bugs.

Or help us out, I hear 3.2.2 MU3 is in controlled release. We need more beta testers!

[Namlehse]

For an interesting turn of events, I received this in email today.

http://h20566.www2.hpe.com/hpsc/doc/pub ... ritical__/

[Namlehse]

I got the same thing when trying to upgrade.

Hello Brandon,

Please be informed that as per HPE StoreServ Engineering the recommended HPE 3PAR OS version for P7000 &P10000 arrays is 3.2.1.MU5. Kindly let us know the reason if you wish to upgrade to 3.2.2 EMU2.

Thanks & Regards,

Swathi N
Service Segment Manager
COE - Global Deployment Center
Customer Solution Center

[MammaGutt]

I got the same thing when trying to upgrade.

Hello Brandon,

Please be informed that as per HPE StoreServ Engineering the recommended HPE 3PAR OS version for P7000 &P10000 arrays is 3.2.1.MU5. Kindly let us know the reason if you wish to upgrade to 3.2.2 EMU2.

Thanks & Regards,

Swathi N
Service Segment Manager
COE - Global Deployment Center
Customer Solution Center

"I need the feature enhancements for AO included in 3.2.2" should be a valid response? Worked for me a couple of months back.

Wanting to avoid a possible issue stated in an advisory should also be very valid.

[bajorgensen]

I guess there are too many vSphere specific bugs at the moment…
Checked SPOCK by chance and found this little support gem. No advisory or notification as far as I can determine.

ESXi6.0U2 Notes

• 1) ESXi6.0u2 is supported with the following 3PAR OS levels only:
o 1a) 3PAR OS version 3.1.3.MU3 with Patch 21
o 1b) 3PAR OS version 3.2.1.MU3 with Patch 37
o 1c) 3PAR OS version 3.2.1.MU5
o 1d) 3PAR OS version 3.2.2.MU2 with Patch 27
o 1e) 3PAR OS version 3.2.2.MU3
• 2) Online upgrades are limited to upgrading to 3.2.1MU5 and 3.2.2.MU3
This is what HPE support replied regarding 3.2.2 MU2 P33 released now in August:

“I checked this with Level 2 and got the following response:

P33 has several improvements that eliminate the "lun timeouts" and "bus resets" associated with the ESX ATS heartbeat.
It is strongly recommended that in ESX environment that experiences LUN timeouts, 3PAR array running 3.2.2 be updated to P33. For Patch installation & details, contact the 3DC team.»

As per the advisory there is no fix for 3.2.1 yet, we are trying to determine when that will be available.

http://h20566.www2.hpe.com/hpsc/doc/pub ... ritical__/

So with 3.2.2 MU3 in controlled release, what do we do?

[MammaGutt]

Are you sure 3.2.2 MU3 is a controlled release?

Either way I would be surprised if we're talking weeks until a 3.2.1 patch equal to P33 is available.

The only advisory I've seen regarding 3.2.2 MU3 P33 is regarding ATS heartbeat which seems to affect more than just 3PARs. A workaround for this can also be done at the host level.

[ailean]

3.2.1mu3 P38 (replaces P37) mentions some of the same fixes in P33 but not the ATS one, not that HP are that open about ESX fixes (e.g. all the 6.0u2 issues).
I've got my fingers crosses that 3.2.2 MU3 is nice and stable, if so I'll be moving all our arrays to that (if they approve it for 10000 and 8000 models ).