SnapCenter SnapMirror or SnapVault update fails with "Another transfer is already in progress"

Applies to

• SnapCenter Server (SC) 5.x and above
• SnapCenter Plug-in for Microsoft SQL Server (SCSQL) 5.x and above
• SnapCenter Plug-in for Exchange (SCE) 5.x and above

Issue

• Backup job ends in a Warning, showing that the SnapMirror or SnapVault update request ended with the following message:
  • ErrorCode (-1), ErrorMessage (Snapmirror update failed with SDError (102) - SnapMirror update operation failed.
Failed to update the SnapMirror relationship. Another transfer is in progress.
  • SnapVault update failed for the relationship [<SOURCE_PATH> ==> <DESTINATION_PATH>] with error: Snapmirror update failed with SDError (102) - SnapMirror update operation failed.
Failed to update the SnapMirror relationship.
The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Another transfer is in progress.
• SNAPMIRROR-AUDIT-LOG-TXT.GZ on ONTAP also indicates Another transfer is in progress.

ManualUpdate[<TIMESTAMP>]:<RELATIONSHIP_ID> Operation-Uuid=<UUID> Group=none Operation-Cookie=0 action=Start source=<SOURCE_PATH> destination=<DESTINATION_PATH>
ManualUpdate[<TIMESTAMP>]:<RELATIONSHIP_ID> Operation-Uuid=<UUID> Group=none Operation-Cookie=0 action=End source=<SOURCE_PATH> destination=<DESTINATION_PATH> status=Failure message=Another transfer is in progress.

Cause

• The backup that created the Snapshot on the volume ran while a previous backup was still updating the SnapMirror or SnapVault relationship.
• With default settings, after 8 update attempts in 8 seconds, it runs a sub-job which will attempt to run the update 9 more times with a 1 minute pause in between each attempt. If the previous transfer has not finished by then, the backup fails out the mirror or vault update, and will not register the snapshot.
• The destination has setup an update schedule in ONTAP that conflicts with the backup timing, causing extra updates.
• Two different backups, where resources share the same volume, are run in overlap or simultaneously from different hosts.

Solution

• For Windows Plug-In host related backups, the following changes need to happen on the Windows Plug-In hosts, not on the SC Server host.
• If using SC 5.x and above, increase the total number of times SC will retry the transfer:

1. Locate the SMCoreServiceHost.exe.config file (SC 5.x) or SMCoreServiceHost.dll.config (SC 6.x and higher), which resides in %Program Files%\NetApp\SnapCenter\SMCore
2. Open the config file in a text editor, and go to the end of the file, just above </AppSettings>
3. Insert the following  lines:

<add key="SnapshotCheckRetry" value="300" />
<add key="SnapshotCheckTimeout" value="300000" />
<add key="SnapmirrorRetry" value="300" />
<add key="SnapmirrorTimeout" value="300000" />

• The above entries mean that SC checks 300 times every 5 minutes (300000 milliseconds). The values can be adjusted accordingly.
• Make sure no operations from SC are running on the Plug-In hosts or the SC Server (check the Monitor in the SC UI)
• Restart the SC SMCore service on the SC plug-in host

Notes:

Do not schedule mirror (specifically vault) updates ONTAP side when SC is supposed to handle them.
Do not use the same volume with LUNs divided between between two or more hosts, and not mapped to all of them (i.e. non-shared LUNs).

Additional Information

Parent topic: Resolution guide for SnapMirror/SnapVault issues in SnapCenter