When Copy Set are removed from Sessions with DS8000 GM role pairs, the GM Master may continue to form CGs and therefore is not stopped/restarted even in case a GM Master reconfiguration might make sense. For example, if all Volumes from a Master LSS are removed (or even all volumes from a Master system in a Master / Subordinate topology), a controlled restart of the GM Master might make sense to start the Master on an existing LSS of the CSM session. Otherwise it could result in subsequent errors when the HW resources used by CSM to control the active GM Master are also removed or disconnected. Therefore the System removal steps and GM Master recreation steps are described in the KC for the removal of complete Storage Systems:
https://www.ibm.com/support/knowledgecenter/SSESK4_6.2.10/com.ibm.storage.csm.help.doc/csm_t_removing_ss_active_gm_csm_session.html
However, there is currently no indication to users once they removed all session volumes from an active Master LSS. Even worse is the situation when all volumes from the Master LSS are deleted subsequently on the HW (due to a storage reconfiguration project). CSM will loose control of the active Master since the LSS does not exist anymore. This loss of Master control is not reflected in any way and session actions may get stuck, leaving an unmanagable session, even if the GM Master could still be controlled through another existing LSS from the same odd/even LSS group.
Following changes are suggested, if CSM will receive an HW error that the Master LSS does not exist/does not contain any volume:
- Flag an error on the GM role pair. Session should flag a severe state as well
- The GM details tab could contain additional details of the error if necessary
- When a StartGM for the GM role pair is issued while this error exists, CSM should internally try to recover the Master control capability. Eg. CSM should try to query/remove the active Master through another existing LSS of the system and restart a new Master according the actual CSM session HW topology.
- The GM role pair error should be reset once the Master control is recovered or the Master is removed/cleared in any session sequence
- When the GM CG name is changed while this error is active, the internal Master control through another LSS should also be recovered first, to ensure the existing ID is cleared properly and conflicts are avoided.
A one time Warning to users for such a potential GM Master configuration mismatch could also be presented at the end of the Copy Set Removal process, in case no further active CSM session contains devices from the Master LSS. Then users are alerted and may enforce a restart of the GM Master if desired, using the procedure described in the Knowledge Center.