When we reprotect after an SRM failover it seems that SRA steps on itself a bit in the process. As noted in the snapmirror_audit snippet below, SRA creates the SnapMirror relationship and attempts to resync (actually it issues an Initialize request first) which fails then immediately retries with a successful resync operation.
The main problem here is that vSphere hangs onto the FAILURE so a rediscover of devices in SRA is required in order to clear the error and make everyone (i.e. our management) happy. I suspect this is a bug?
I have edited the entries to simplify display:
Wed Sep 4 14:11:09 EDT 2019 Create action=Start source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror
Wed Sep 4 14:11:09 EDT 2019 Create action=End status=Success source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror
Wed Sep 4 14:11:09 EDT 2019 Initialize[Sep 4 14:11:09] action=Start source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror
Wed Sep 4 14:11:09 EDT 2019 Initialize[Sep 4 14:11:09] action=End source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror status=Failure message=Destination DEST:SOURCE_SRM_Test_vol_mirror must be a data-protection volume.
Wed Sep 4 14:11:11 EDT 2019 ResyncSetup[Sep 4 14:11:11] action=Start source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror
Wed Sep 4 14:11:13 EDT 2019 ResyncSetup[Sep 4 14:11:11] action=End source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror status=Success
Wed Sep 4 14:11:13 EDT 2019 ResyncTransfer[Sep 4 14:11:13] action=Start source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror
Wed Sep 4 14:11:36 EDT 2019 ResyncTransfer[Sep 4 14:11:13] action=End source=SOURCE:SRM_Test_vol destination=DEST:SOURCE_SRM_Test_vol_mirror status=Success bytes_transferred=199798784 network_compression_ratio=1.0:1 transfer_desc=Physical Transfer
