This is a limitation on the Netapp cDOT design in my mind. But I also was thinking that you were attacking this from the wrong end, where you started at the destination and worked backwards. But I can see how that's a valid decision on your part to go that route.
Mark> "then once you find the destination" Mark> This is the part that is in question - Mark> Given a cluster and volume how do you find the cluster/SVM management address of the mirror/vault source/destination.
This is a problem, since it's not explicit, nor is it really implicit in the naming or setup of the relationship. I don't currently use SM relationships on cDOT, so I can't really contribute much to the discussion.
Mark> You can easily get the cluster and SVM name, but those don't Mark> translate to the management addresses. As Tim said, you can get Mark> the ICL addresses from the peering relationship but I haven't Mark> found anything that will return the management address for a Mark> given peer cluster/SVM.
Mark> In our case, all our clusters have a uniform relationship Mark> between cluster name and management address so I can work around Mark> it - but I couldn't assume that for any other environment.
You're right, it's not something you can assume at all. It's a tricky problem to solve. So if you're running multi-tenant, and you're one of the tenants and are SM'ing to another SVM, which you don't know the admin interface for... your out of luck. This could be because of lack of documentation, someone walking in front of a bus, etc.
I think filing a bug report with Netapp on this or a request for enhancement would be the way to go. The security implications are interesting. If you have VServer admin on both source and destination, but don't know the admin interface for one of them, how do you manage it? Should you be able to find that info? Or should it be locked down?
Mark> -----Original Message----- Mark> From: John Stoffel [mailto:john@stoffel.org] Mark> Sent: Wednesday, January 3, 2018 3:53 PM Mark> To: Weber, Mark A mark-a-weber@uiowa.edu Mark> Cc: Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com; toasters@teaparty.net Mark> Subject: RE: VMware SRM + NetApp SRA + NetApp WFA?
Mark> Wouldn't you already have this information before you start? Or if you start at the primary, then once you find the destination, you would then probe the destination to find out the rest of the information you need?
Mark> Sure, reduce human interactions but assume that you will need to probe both systems to find and match up the configuration. And if it doesn't match exactly, then you have to bail and let the admins decide what to do.