This is one of those questions where it would be fair to ask "what are you trying to do" but right now I am still in a stage of figuring out "what we can and can't potentially do" so as to avoid any road blocks in some automation enhancements (WFA and PoSH) being considered.
My customer has WFA workflows that create SVMs and volumes within them.
The svm-creation-workflow can create a secondary-SVM with it's own LIFs and peer to it (a regular SVM, not a formal SVM-DR).
The vol-creation workflow allows a vol-snapmirror to also be automatically setup to the 'other' secondary SVM at vol-create time. This vol-creation workflow does not 'yet' create exports or shares on the secSVM (and we need to address that).
For the next version of these workflows there is an interest in:
Determing if SVM-DR might be a better approach for the svm-creation-workflow ... to either switch all secondary SVM creation to be SVM-DRs or provide an option for one (regular secSVM) or the other (SVM-DR secSVM). (thou I prefer one or the other)
Also, in the same environment, this customer has some MetroClusters. Right now the svm and vol creation workflows are not MC-aware and part of the next phase will be to allow the svm-creation-workflow to let the user select if they desire sync-mirror-level DR (aka MC) or async-mirror-level, and depending on the choice, determine which clusters offer that level of service and place the SVM on appropriate cluster: A) on a MC cluster, B) on another non-MC cluster.
Lastly, we'd like the svm-creation and vol-creation workflows to support off-MC data protection to a cluster beyond the MetroCluster (maybe only SnapVault, but maybe SnapMirror too).
Now to my question: There is a statement in the ONTAP 9.0 (maybe in 8.3.1 too) SVM DR Express Preparation guide (http://nt-ap.com/2h2hry7) in the 'Deciding whether to use this guide' section that says "The source or destionation cluster is not a MetroCluster Configuration". My question is: Is that warning just saying that 'express guide" doesn't go into the details of how to setup an SVM-DR config when a MC is involved, -OR- that SVM-DR absolutely can not be used when either src or dst SVM live on a MetrocCluster.
Either answer is fine and I understand that one might ask what do you need SVM-DR on top of MC for anyway (our added use-case might be to have have SnapVaults to an off-MC SVM for backup) ... I'm just trying to collect the config facts for the overall discussion and decision in determining if a move to SVM-DR makes sense or should we enhance our use of tradition SVM peering with vol-level SM (and adding SV support and secSVM export/share setup for failover).
PS: additional question might be: any difference in the answer between ONTAP 8.3.1, 9.0 or 9.1 (I don't think so, but ...)
Yes, I was a bit wordy but I was trying to zero in a specific combination of features. I'm aware I can SnapMirror and Vault to a remote peered standard SVM on another cluster. My question is strictly focused on the (new in 8.3.1) SVM-DR style SnapMirror of a complete SVM (living on a MetroCluster aka MC). As I said, one of the Express Guides explicitly says SVM-DR'ing of a MetroCluster is not covered (in the manual) ... and my question is: 'Is it disallowed in general'. I'm beginning to believe it is disallowed and you can't combine MC and SVM-DR because both MC and SVM-DR share the use of MDV_CRS_ volumes to replicate SVM data (i.e.; MC replicating from subtype 'sync-source' to 'sync_destination' SVM) and SVM-DR replicating from subtype 'default' to 'dp-destination' in the remote cluster case)
I think since SVM-DR is really only for SnapMirror use (no vaulting allowed and is really intended for DR only) that this is NOT a major use-case hole. They both provide easy DR setup and the need to layer one on top of the other would be a stretch case ... and even if you do need it (teriary DR somewhere off the MetroCluster), you can still build it using standard peered SVMs, SnapMirror, and customer specific replication of what metadata (exports, shares, etc) is needed.
But if you have the ability to test SVM-DR off a MC, try it and let us know otherwise. I'm just trying to confirm a negative and the literature is a bit fuzzy.