callhome.clus.vol.del.fail

[hard urchin]

Receiving the following error after provisioning and deleting a regular SVM via Ansible Automation Platform.
Receiving this error daily - can anyone help remove and stop it?
Running ONTAP 9.13.1Px however unforunately the EMS reference not very helpful: https://docs.netapp.com/us-en/ontap-ems-9131/callhome-clus-events.html#callhome-clus-vol-del-fail

Node: <redacted>
Time: Wed, Dec 06 15:06:06 2023 -0500
Severity: ERROR

Message: callhome.clus.vol.del.fail: Call home for CLUSTER VOLUME DELETE FAILED. Could not delete volumes "MDV_CRS_54136109fe1a11ecab0f00a098b81cba_B" and "MDV_CRS_54136109fe1a11ecab0f00a098b81cba_A" for feature cross-cluster configuration replication.

Description: This message occurs when the volumes that were used for cluster-wide storage cannot be deleted. If your system is configured to do so, it generates and transmits an AutoSupport (or 'call home') message to NetApp technical support and to the configured destinations. Successful delivery of an AutoSupport message significantly improves problem determination and resolution.

Corrective Action: Study the error message and take steps to rectify the problem. For example, if the error message indicates that the volume delete failed because the aggregate is offline, use the 'aggr online -aggregate aggregate_name' command to bring it back online. If the error message does not indicate an obvious problem, contact NetApp technical support

Source: mgwd
Sequence#: 373128

[sweet pagoda]

You have auditing enabled. You are not allowed to simply select MDV (metadata) volumes

[hard urchin]

@sweet pagoda - Vserver/SVM-level auditing currently disabled:
::> vserver audit show
This table is currently empty.

We were testing SVM-DR between this cluster and another one and we used Ansible automation to delete the destination vserver.

What's the best way to clean up these remnants?

Found the following KBA:
https://kb.netapp.com/onprem/ontap/dp/SnapMirror/SVM-DR_stopped_working_after_all_MDV_CRS_volumes_been_lost

::> vol show -volume MDV -fields vserver,volume,size,used,available,state,junction-path,policy,percent-used,type,comment,create-time
vserver volume size state policy junction-path comment available used percent-used type create-time

---

ralsan-dev MDV_CRS_54136109fe1a11ecab0f00a098b81cba_A 10GB online - - System volume for CPS Configuration Replication Storage Area Group subsystem. 9.50GB 824KB 0% RW Tue Dec 05 10:01:08 2023
ralsan-dev MDV_CRS_54136109fe1a11ecab0f00a098b81cba_B 10GB online - - System volume for CPS Configuration Replication Storage Area Group subsystem. 9.50GB 812KB 0% RW Tue Dec 05 10:01:12 2023
2 entries were displayed.

::*> debug cps storage-area-group show
Storage Area Group: config-replication-store
Use Mirrored Aggregate: false
Disallowed Aggregates: -
Auto-Repair: true
Auto-Recreate: true
Current Volume: -
Standby Volume: -
Abandoned Volumes: MDV_CRS_54136109fe1a11ecab0f00a098b81cba_B, MDV_CRS_54136109fe1a11ecab0f00a098b81cba_A
Volumes Under Repair: -
Problem Aggregates: -
Active Recreate Retry Count: 0
Standby Recreate Retry Count: 0

[sweet pagoda]

If not auditing then check svm-dr which you just posted 😁

[hard urchin]

@sweet pagoda - yes, it's SVM-DR. How best to safely remove these remnants?

[thorny girder]

audit volumes are called MDV_AUD_...something

CRS is either MCC-IP or SVM-DR (in this case, SVM-DR). Make sure you have deleted all SVM-DR relationships (both incoming and outgoing, i.e. snapmirror show and snapmirror list-destinations)

[hard urchin]

Confirmed... SVM-DR relationships deleted on both SRC and DST. Okay to manually delete both those MDV* audit volumes?