Skip to content

netapp: auto-recover replicas stuck behind source volume clone split - #363

Open
Carthaca wants to merge 1 commit into
stable/2025.1-m3from
maurice-escher-sap-netapp-replica-recovery-analysis
Open

Carthaca wants to merge 1 commit into
stable/2025.1-m3from
maurice-escher-sap-netapp-replica-recovery-analysis

Conversation

@Carthaca

@Carthaca Carthaca commented Sep 7, 2026

Copy link
Copy Markdown
Collaborator

Replica create/mount and the periodic replica state update could get
stuck when creating a SnapMirror snapshot failed with:

Volume Clone Split is in progress on the source volume.

wait_for_mount_replica() treated any terminal SnapMirror error as
permanent and raised NetAppException immediately, so periodic updates
never retried. Separately, update_replica_state() treated any
NaApiError from create/resync as STATUS_ERROR, which also stopped
automatic recovery once the transient backend condition cleared.

Also, for a SnapMirror relationship that is present but still
'uninitialized' (baseline transfer never completed), periodic update
called snapmirror resume/resync instead of snapmirror initialize.
Per NetApp documentation, resync resynchronizes a previously
initialized relationship (e.g. broken-off, or missing a common
snapshot); it does not start the baseline transfer. An uninitialized
relationship therefore never progressed even after the clone split
condition cleared.

Add a shared clone-split matcher and:

  • wait_for_mount_replica(): retry (ShareBusyException) instead of
    failing fast when the terminal SnapMirror error is caused by a
    source volume clone split still in progress.
  • update_replica_state(): keep the replica in
    REPLICA_STATE_OUT_OF_SYNC (instead of STATUS_ERROR) when
    create/initialize/resync fails due to the same transient clone
    split condition, so the next periodic replica state update retries
    automatically.
  • update_replica_state(): call snapmirror initialize (not
    resume/resync) when the relationship is still uninitialized, so it
    can actually complete its baseline transfer once the source volume
    clone split finishes.

Change-Id: Id8d85400eb2990b455d4fede60c342d7bf62509a
Signed-off-by: Maurice Escher maurice.escher@sap.com
Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com

@kpawar-sap

Copy link
Copy Markdown

can you rebase, py3 would pass.

Replica create/mount and the periodic replica state update could get
stuck when creating a SnapMirror snapshot failed with:

  Volume Clone Split is in progress on the source volume.

wait_for_mount_replica() treated any terminal SnapMirror error as
permanent and raised NetAppException immediately, so periodic updates
never retried. Separately, update_replica_state() treated any
NaApiError from create/resync as STATUS_ERROR, which also stopped
automatic recovery once the transient backend condition cleared.

Also, for a SnapMirror relationship that is present but still
'uninitialized' (baseline transfer never completed), periodic update
called snapmirror resume/resync instead of snapmirror initialize.
Per NetApp documentation, resync resynchronizes a previously
initialized relationship (e.g. broken-off, or missing a common
snapshot); it does not start the baseline transfer. An uninitialized
relationship therefore never progressed even after the clone split
condition cleared.

Add a shared clone-split matcher and:
- wait_for_mount_replica(): retry (ShareBusyException) instead of
  failing fast when the terminal SnapMirror error is caused by a
  source volume clone split still in progress.
- update_replica_state(): keep the replica in
  REPLICA_STATE_OUT_OF_SYNC (instead of STATUS_ERROR) when
  create/initialize/resync fails due to the same transient clone
  split condition, so the next periodic replica state update retries
  automatically.
- update_replica_state(): call snapmirror initialize (not
  resume/resync) when the relationship is still uninitialized, so it
  can actually complete its baseline transfer once the source volume
  clone split finishes.

Change-Id: Id8d85400eb2990b455d4fede60c342d7bf62509a
Signed-off-by: Maurice Escher <maurice.escher@sap.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@Carthaca
Carthaca force-pushed the maurice-escher-sap-netapp-replica-recovery-analysis branch from 889c786 to a459116 Compare September 8, 2026 13:55
@Carthaca

Copy link
Copy Markdown
Collaborator Author

I had to retrigger the checks, now they are green :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants