Loading...
Loading...
When upgrading the HPE Alletra Storage MP B10000 Operating System HPE strongly recommends switching all Active Peer Persistence primary groups to the peer array (the array not undergoing the OS upgrade) to avoid a rare service disruption that may occur if a group has the primary role on the array being upgraded.
HPE Alletra Storage MP B10000 arrays running Active Peer Persistence may be impacted by this issue during an OS upgrade.
This issue will be resolved in a future version of HPE Alletra MP B10000. This advisory will be updated when a solution becomes available.NOTE: Switchover of a Peer Persistence group (classic or active-active) automatically redirects host I/O to the array where the group's role is “Primary.” Therefore, it is not necessary to move all host IOPS to the other side. Performing the switchover of the Peer Persistence group is sufficient to ensure I/O is directed to the appropriate array during the OS upgrade.As a workaround, after reviewing this procedure, contact your local countryHPE Customer Supportif you have questions or concerns.Before executing the OS upgrade:1. Capture the Remote Copy Group (RCG) configuration.# showrcopy -d(on both arrays)2. Check for stuck_ioctl# setsysmgr stuck_ioctl3. Validate theactive_activeconfiguration is properly configured.Confirm the Host Proximity is set properly on both arrays.This can be verified by reviewing the output of theshowhostsetcommand. For each remote copy group in anactive_activerelationship, a hostset named RH?_<remote copy group name> will be present, where “?” is 0, 1, or 2.For example, if a hostset namedRH0_my-rcopy-grouplists servers “serverA” and “serverB,” the partner array should contain a hostset namedRH1_my-rcopy-grouplisting the same servers “serverA” and “serverB.”Any differences must be addressed before proceeding with the remote copy group switchover described below.If the hostset begins with RH2_, the corresponding hostset on the partner array will also begin with RH2_.This verification can be difficult in large environments. If assistance is required, contact your local countryHPE Customer Supportand reference Document ID a00158711en_us. HPE Services has a tool to perform this verification.Finally, confirm that the volumes in the remote copy groups are exported to the same servers on both arrays.4. Verify multipath connectivity from each host to ensure all paths to the storage array are healthy.5. On the array that is having the Operating System upgraded, switch over any groups that are reported as "Primary" to the peer array (array not being upgraded).NOTE: This switchover ensures all host I/O is redirected to the array where the group's role is now “Primary,” without requiring manual movement of host IOPS.# setrcopygroup switchover <groupname>(executed from the current primary role for the group)6. Again, verify multipath connectivity from each host to ensure all paths to the storage array are healthy.7. Execute the standard OS upgrade procedure.8. Once the OS upgrade completes, check the RCGs. If any of them have stopped unexpectedly, restart them.# startrcopygroup <groupname>9. If preferred, return the RCGs back to the original captured RCG configuration (switchover the groups back to their original roles).# setrcopygroup switchover <groupname>(executed from the current primary role for the group)10. Repeat the process to upgrade the peer array starting at Step 4.Revision HistoryDocument VersionRelease DateDetails2April 24, 2026In the Resolution section, added a Note after the first paragraph and added content to Steps 5 and 9.1April 14, 2026Original Document Release
Operating Systems Affected:Not Applicable
Click on a version to see all relevant bugs
Hewlett Packard Enterprise Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.