7200 OS Upgrade to 3.2.2

[Namlehse]

We went from

Release version 3.2.1.120 (MU1)
Patches: P02,P04,P06

Component Name Version
CLI Server 3.2.1.120 (MU1)
CLI Client 3.2.1.120
System Manager 3.2.1.140 (P04)
Kernel 3.2.1.120 (MU1)
TPD Kernel Code 3.2.1.140 (P04)
TPD Kernel Patch 3.2.1.140 (P04)

to

Release version 3.2.2.530 (MU3)
Patches: None

Component Name Version
CLI Server 3.2.2.530 (MU3)
CLI Client 3.2.2.530
System Manager 3.2.2.530 (MU3)
Kernel 3.2.2.530 (MU3)
TPD Kernel Code 3.2.2.530 (MU3)

Which took several hours. Still have to do the firmware upgrade on the cages and drives. For some reason I have a battery at 37%, which failed the firmware upgrade.

2016-09-07 10:40:59 CDT Updated Checking cage firmware...
2016-09-07 10:40:59 CDT Updated 7 cages require firmware upgrades.
2016-09-07 10:40:59 CDT Updated This will require approximately 70-140 minutes.
2016-09-07 10:40:59 CDT Updated 2016-09-07 15:40:59 +0000
2016-09-07 10:40:59 CDT Updated Upgrading cage cage0 cpuA from rev 3219 to revision in file /opt/tpd/fw/cage/ebod/hp_eos_canister_local_combined_v406a.gff.
2016-09-07 10:43:55 CDT Updated Upgrading cage cage0 cpuB from rev 3219 to revision in file /opt/tpd/fw/cage/ebod/hp_eos_canister_local_combined_v406a.gff.
2016-09-07 10:48:52 CDT Error Error: Opcode = SCCMD_DOCDB
2016-09-07 10:48:52 CDT Error Node = 253
2016-09-07 10:48:52 CDT Error Tpd error code = TE_INVALID -- Invalid input parameter
2016-09-07 10:48:52 CDT Error Tpd error info = Cage 0, PCM_VPD 0, Firmware download failed. Redundant battery protection unavailable at this time. PS State (self: Normal, partner: Normal), Battery State (self: Normal, partner: Normal), Battery Protection available, Retries (state: 4, verification 0, download: 0), Version: B28A359E, Filename: /opt/tpd/fw/cage/ebod/0949322_764w_pcm_vpd_v5_0ab1f1e8_slot1.gff
2016-09-07 10:48:52 CDT Error
2016-09-07 10:48:52 CDT Error Task exited with status 1
2016-09-07 10:48:52 CDT Failed Could not complete task.

----------Node 0 PS 1 Battery 0----------
Node ID : 0
Power Supply ID : 1
Battery ID : 0
Manufacturer : XYRATEX
Assembly Part : 683542-001
Assembly Serial Number : 6CQUBA1HN3018M
State : OK
Detail State : normal
Charge Level(%) : 37
Expired : No
Test in Progress : No
Charge State : Charging
Max Battery Life(Whrs) : 16
Expiration Date : n/a
Fault LED : Unknown
Status LED : Unknown
Discharge LED : Unknown

It's back to 100% today.

[cjh]

3.2.2 is the minimum version for 8x and 20x therefore they have to run it and 7x and 10x does not.

3.2.2 has lots of new features - Good advice is switch to new features once they have matured, particularly with older equipment.

[Patrick]

Similar story here with three 7k units. Did a series of smaller patches, then 3.2.2 EMU3, and some small patches on our two smaller units. Outside of a faulty hardware 1/2 through the upgrade on one controller it went smooth.

Opened up a support ticket with HPE to have the last 7400 upgraded, got a week of run-around due to requesting 3.2.2. The would only load a more recent release of 3.2.1 on the array. Yes, we are running remote copy between versions and it works fine.

Since then I've tried loaded on some smaller patches but have been getting bit on under 3.2.1 and 3.2.2 where the array has a patch installed but the SP doesn't believe it leaving the customer rev-locked until they call HPE to have them run some internal scripts and load the patches for you.

I have no problem involving HPE for major code upgrades but when a bug fix patch is released going down this route is a 3-week process and taking hours of staffing time on our end vs spending the 5 minutes to just patch the array.

[AppleADay]

We have several 3PAR 7200 models and after requesting an upgrade we are facing the same dilemma. Upgrade to 3.2.1 MU5 or 3.2.2 MU3?
Initially we wanted to upgrade because of the ATS bug, but in the release notes for 3.2.2 MU3 I also found another issue which makes me prefer an upgrade to 3.2.2 MU3 (see below).

Can anyone share their experiences with 3.2.2 MU3?

=-=-=-=-=
HPE 3PAR StoreServ Storage – ESX 6.0x servers freeze and lose paths to the array when doing rescans

Description
ESX servers running 6.0x connected to a 3PAR array could experience path issues leading to freezing VMs when a lun rescan has been initiated.

In ESXi 6.0 Update 2, a change to the PDL response behavior can result in this condition blocking additional IO operations, resulting in the aborts and timeouts described in the Symptoms section. For more information, see General Storage Issues section in the ESXi 6.0 Update 2 Release Notes.

Scope
This issue affects VMware hosts running VMware 6.0 or later connecting to HPE 3PAR StoreServ arrays running all versions of HPE 3PAR OS 3.2.2 or 3.2.1.

Resolution
HPE has released HPE 3PAR OS 3.2.2 MU3 with enhancements to address this behavior of the hosts to minimize the likelihood of experiencing this issue (Refer to KB article: http://kb.vmware.com/kb/2133286)

[cjh]

Hi AppleADay,

I would stick on 3.2.1 for now unless there is a feature in 3.2.2 you need.

The VMware v6 issue you mention is fixed in 3.2.1 MU3 P37 which is included in MU5 along with the ATS fix and others. Its a solid release.

Cheers...

[audiojim]

Just refreshing this thread to see if anything has changed over the past three months...

SPOCK still shows 3.2.1 MU5 is the default for the 7000 series. I'm at 3.2.1 MU5 + P39,P44,P49 on our 7200c (though I see 3.2.1 MU5 P53 is now out).

I've held our vSphere hosts steady at a patched ESXi 5.5, but as I look to the future of maybe upgrading beyond 5.5 when I drop in new hosts, I want to look at the 3PAR side first.

Aside from all of the feature additions, and now that 3.2.2 seems to be much more stable on the 7000 series than I was hearing before, is there anything like TDVV performance improvements that might make it worthwhile for me to upgrade to it?

Thanks!
-Jim

[bajorgensen]

3.2.1 is still the default version for 7k/10k.

Rumor is that 3.2.2 MU4 is candidate for a joint default version,
I think HPE is still awaiting a certain adoption rate and stability period.

We have one 7k on 3.2.2 MU3 ++ and it seems quite solid.
Still some issues running tunesys.
If you are adventurous you could order an upgrade to 3.2.2 MU4,
with the expectation that it will become default.

[bajorgensen]

Just got news that 3.2.2 MU4 is new default version for 7k/8k/10k/20k series!!!
I will assume this is a pretty solid version.

Think we'll upgrade to this and let all you muppets enjoy the bug squashing with HPE support on 3.3.1...:

[bajorgensen]

Default version documentation:

https://h20272.www2.hpe.com/spock/utili ... _02_20.pdf

[audiojim]

Nice!