Mailing List Archive

I've been working on this off and on between my regular duties, then delayed by holiday breaks, etc.

Something I haven't been able to figure out is how to programmatically get a Snapmirror relationship's source cluster management address hostname (or even just an IP address). I can easily get the source vserver name, source volume name, and even a pre-constructed combination of the two from what Get-NcSnapmirror returns when run against the destination controller.

In essence, I want to be able to pass to this script three arguments: Current Snapmirror destination cluster mgmt address, current snapmirror destination vserver, and current Snapmirror destination volume. Then do some stuff to extract the rest of the required information out to reverse the relationship and resync, such as current snapmirror source cluster address, current snapmirror source vserver, and current snapmirror source volume. I'm 66% of the way there, it's the current snapmirror source cluster address that I can't see to pull out of anywhere.

I was playing around with Get-NcVserverPeer when run against a Snapmirror destination, but I can't seem to get what I want there.

Any hints from people who have done this before? Thanks so much.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com


________________________________________
From: Ehrenwald, Ian
Sent: Thursday, December 14, 2017 11:40:41 AM
To: toasters@teaparty.net
Subject: VMware SRM + NetApp SRA + NetApp WFA?

This isn't 100% NetApp related, more like 60%, but I think it's still a relevant topic of discussion that others may eventually benefit from too.

I've been tasked with setting up DR for a set of VMware VMs at our primary data center by replicating them via SnapMirror to our secondary data center. Normally I'd just use VMware SRM with the NetApp SRA, set up Array Based Replication within SRM, and be done with it. Let SRM and the SRA take care of test, failover, reprotect, etc.

However, the sticking point is that a lot of the protected VMs use in-guest NFS mounts for things like database volumes or application binaries and SRM doesn't know what to do with those SnapMirror pair volumes because they're not VMware datastores.

My initial thought was to use some PowerShell with the NetApp PowerShell Toolkit in the SRM Recovery Plan for each individual VM pre-boot to connect to the SnapMirror destination filer, break the SnapMirror(s) that the VM uses, mount the volume(s), set export policies, etc. Then figure out how to correctly do resync and reprotect without blowing things up.

I got as far as the first part in PowerShell (connect to the destination filer, break the mirror) and thought to myself that this was stupid.. I'm re-inventing the wheel. Surely someone else out there must have done this before and there is a pre-existing solution? I spoke with a NetApp tech support engineer that I happened to have a case open with already regarding the NetApp SRA and he was able to come up with a suggestion from another engineer: Call WFA from SRM in each VMs recovery plan to break the SnapMirror for the volumes required for the VM to work, then also use WFA in the cleanup and reprotect plan to do that work.

Has anyone else done something like this? I have a feeling that I'm not breaking new ground with this task. Implementing it wrong has pretty severe implications, though, so I'm not eager to mess it up.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com

This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

I don't think you will be getting that the way you think.

SnapMirror in Clustered ONTAP is vastly different.
For starters, you are supposed to have at least one Intercluster LIF per
node.
This is because when SnapMirror kicks off, it will use the InterCluster LIF
on the node that the volume actually resides.

If you do a "vol move" from node 1 to node, the next time, SnapMirror will
use the InterCluster LIF on node 2.

Same idea goes for the destination IP. It will go to where ever the
volume/aggregate resides.

To get the source address, you will need to do some calculations:
source volume name -> aggregate name -> aggregate owner -> intercluster LIF
on node owner.
That would be your source address. Again, if the volume changes nodes, then
the source address will change!


--tmac

*Tim McCarthy, **Principal Consultant*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*


On Wed, Jan 3, 2018 at 11:11 AM, Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.com>
wrote:

> I've been working on this off and on between my regular duties, then
> delayed by holiday breaks, etc.
>
> Something I haven't been able to figure out is how to programmatically get
> a Snapmirror relationship's source cluster management address hostname (or
> even just an IP address). I can easily get the source vserver name, source
> volume name, and even a pre-constructed combination of the two from what
> Get-NcSnapmirror returns when run against the destination controller.
>
> In essence, I want to be able to pass to this script three arguments:
> Current Snapmirror destination cluster mgmt address, current snapmirror
> destination vserver, and current Snapmirror destination volume. Then do
> some stuff to extract the rest of the required information out to reverse
> the relationship and resync, such as current snapmirror source cluster
> address, current snapmirror source vserver, and current snapmirror source
> volume. I'm 66% of the way there, it's the current snapmirror source
> cluster address that I can't see to pull out of anywhere.
>
> I was playing around with Get-NcVserverPeer when run against a Snapmirror
> destination, but I can't seem to get what I want there.
>
> Any hints from people who have done this before? Thanks so much.
>
>
> Ian Ehrenwald
> Senior Infrastructure Engineer
> Hachette Book Group, Inc.
> 1.617.263.1948 / ian.ehrenwald@hbgusa.com
>
>
> ________________________________________
> From: Ehrenwald, Ian
> Sent: Thursday, December 14, 2017 11:40:41 AM
> To: toasters@teaparty.net
> Subject: VMware SRM + NetApp SRA + NetApp WFA?
>
> This isn't 100% NetApp related, more like 60%, but I think it's still a
> relevant topic of discussion that others may eventually benefit from too.
>
> I've been tasked with setting up DR for a set of VMware VMs at our primary
> data center by replicating them via SnapMirror to our secondary data
> center. Normally I'd just use VMware SRM with the NetApp SRA, set up Array
> Based Replication within SRM, and be done with it. Let SRM and the SRA
> take care of test, failover, reprotect, etc.
>
> However, the sticking point is that a lot of the protected VMs use
> in-guest NFS mounts for things like database volumes or application
> binaries and SRM doesn't know what to do with those SnapMirror pair volumes
> because they're not VMware datastores.
>
> My initial thought was to use some PowerShell with the NetApp PowerShell
> Toolkit in the SRM Recovery Plan for each individual VM pre-boot to connect
> to the SnapMirror destination filer, break the SnapMirror(s) that the VM
> uses, mount the volume(s), set export policies, etc. Then figure out how
> to correctly do resync and reprotect without blowing things up.
>
> I got as far as the first part in PowerShell (connect to the destination
> filer, break the mirror) and thought to myself that this was stupid.. I'm
> re-inventing the wheel. Surely someone else out there must have done this
> before and there is a pre-existing solution? I spoke with a NetApp tech
> support engineer that I happened to have a case open with already regarding
> the NetApp SRA and he was able to come up with a suggestion from another
> engineer: Call WFA from SRM in each VMs recovery plan to break the
> SnapMirror for the volumes required for the VM to work, then also use WFA
> in the cleanup and reprotect plan to do that work.
>
> Has anyone else done something like this? I have a feeling that I'm not
> breaking new ground with this task. Implementing it wrong has pretty
> severe implications, though, so I'm not eager to mess it up.
>
>
> Ian Ehrenwald
> Senior Infrastructure Engineer
> Hachette Book Group, Inc.
> 1.617.263.1948 / ian.ehrenwald@hbgusa.com
>
> This may contain confidential material. If you are not an intended
> recipient, please notify the sender, delete immediately, and understand
> that no disclosure or reliance on the information herein is permitted.
> Hachette Book Group may monitor email to and from our network.
>
>
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> http://www.teaparty.net/mailman/listinfo/toasters
>

Hi Tim
Thanks for the speedy reply.

Forgive me, but I don't see source volume name, source aggregate name, source aggregate owner, or source intercluster LIF in the object properties that Get-NcSnapmirror returns. I'm sure I'm misunderstanding where you're going with it. I don't see how I would get that information at all, just given the input parameters of current destination cluster mgmt, current destination vserver, and current destination volume.

The reason I'd like to get the source cluster management hostname out of this is so I can Connect-NcController to it, then run Get-NcSnapmirrorDestination against it to verify that both sides of the Snapmirror relationship agree upon the state of things before proceeding. Then, I'd run Remove-NcSnapmirror against the current destination, then Invoke-NcSnapmirrorRelease against the current source, then New-NcSnapmirror against the current source to turn it into the destination side, then Invoke-NcSnapmirrorResync against the current source to actually do the reverse resync.

I know all of this works, because when I manually feed my script the information I am trying to programmatically get, it succeeds in both directions, and I can flip flop all day. However, I want to reduce the number of human inputs as much as possible for this critical operation, and the more that can be determined by a machine instead of a stupid human, the better :)


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com


________________________________________
From: tmac <tmacmd@gmail.com>
Sent: Wednesday, January 3, 2018 11:30:00 AM
To: Ehrenwald, Ian
Cc: toasters@teaparty.net
Subject: Re: VMware SRM + NetApp SRA + NetApp WFA?

I don't think you will be getting that the way you think.

SnapMirror in Clustered ONTAP is vastly different.
For starters, you are supposed to have at least one Intercluster LIF per node.
This is because when SnapMirror kicks off, it will use the InterCluster LIF on the node that the volume actually resides.

If you do a "vol move" from node 1 to node, the next time, SnapMirror will use the InterCluster LIF on node 2.

Same idea goes for the destination IP. It will go to where ever the volume/aggregate resides.

To get the source address, you will need to do some calculations:
source volume name -> aggregate name -> aggregate owner -> intercluster LIF on node owner.
That would be your source address. Again, if the volume changes nodes, then the source address will change!


--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeam<https://twitter.com/NetAppATeam>

I Blog at TMACsRack<https://tmacsrack.wordpress.com/>


On Wed, Jan 3, 2018 at 11:11 AM, Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.com<mailto:Ian.Ehrenwald@hbgusa.com>> wrote:
I've been working on this off and on between my regular duties, then delayed by holiday breaks, etc.

Something I haven't been able to figure out is how to programmatically get a Snapmirror relationship's source cluster management address hostname (or even just an IP address). I can easily get the source vserver name, source volume name, and even a pre-constructed combination of the two from what Get-NcSnapmirror returns when run against the destination controller.

In essence, I want to be able to pass to this script three arguments: Current Snapmirror destination cluster mgmt address, current snapmirror destination vserver, and current Snapmirror destination volume. Then do some stuff to extract the rest of the required information out to reverse the relationship and resync, such as current snapmirror source cluster address, current snapmirror source vserver, and current snapmirror source volume. I'm 66% of the way there, it's the current snapmirror source cluster address that I can't see to pull out of anywhere.

I was playing around with Get-NcVserverPeer when run against a Snapmirror destination, but I can't seem to get what I want there.

Any hints from people who have done this before? Thanks so much.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948<tel:1.617.263.1948> / ian.ehrenwald@hbgusa.com<mailto:ian.ehrenwald@hbgusa.com>


________________________________________
From: Ehrenwald, Ian
Sent: Thursday, December 14, 2017 11:40:41 AM
To: toasters@teaparty.net<mailto:toasters@teaparty.net>
Subject: VMware SRM + NetApp SRA + NetApp WFA?

This isn't 100% NetApp related, more like 60%, but I think it's still a relevant topic of discussion that others may eventually benefit from too.

I've been tasked with setting up DR for a set of VMware VMs at our primary data center by replicating them via SnapMirror to our secondary data center. Normally I'd just use VMware SRM with the NetApp SRA, set up Array Based Replication within SRM, and be done with it. Let SRM and the SRA take care of test, failover, reprotect, etc.

However, the sticking point is that a lot of the protected VMs use in-guest NFS mounts for things like database volumes or application binaries and SRM doesn't know what to do with those SnapMirror pair volumes because they're not VMware datastores.

My initial thought was to use some PowerShell with the NetApp PowerShell Toolkit in the SRM Recovery Plan for each individual VM pre-boot to connect to the SnapMirror destination filer, break the SnapMirror(s) that the VM uses, mount the volume(s), set export policies, etc. Then figure out how to correctly do resync and reprotect without blowing things up.

I got as far as the first part in PowerShell (connect to the destination filer, break the mirror) and thought to myself that this was stupid.. I'm re-inventing the wheel. Surely someone else out there must have done this before and there is a pre-existing solution? I spoke with a NetApp tech support engineer that I happened to have a case open with already regarding the NetApp SRA and he was able to come up with a suggestion from another engineer: Call WFA from SRM in each VMs recovery plan to break the SnapMirror for the volumes required for the VM to work, then also use WFA in the cleanup and reprotect plan to do that work.

Has anyone else done something like this? I have a feeling that I'm not breaking new ground with this task. Implementing it wrong has pretty severe implications, though, so I'm not eager to mess it up.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948<tel:1.617.263.1948> / ian.ehrenwald@hbgusa.com<mailto:ian.ehrenwald@hbgusa.com>

This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
http://www.teaparty.net/mailman/listinfo/toasters<http://www.teaparty.net/mailman/listinfo/toasters>

This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

I've looked for the same information (going the other way - given the primary, find the cluster management lif of the secondary)
The only thing I've found is:
::*> debug smdb table xc_virtual_interface show

No idea if it is reliable/consistent/etc
And insert standard warning about using debug...
I have caused a panic by just doing a debug smdb table <table> show. I was looping through them all looking for the remote cluster management lifs.

9.3 seems to have added some functionality (snapmirror protect) that may be relevant or expose this info in some consumable way (haven't looked into it yet)

m

-----Original Message-----
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Ehrenwald, Ian
Sent: Wednesday, January 3, 2018 10:48 AM
To: tmac <tmacmd@gmail.com>
Cc: toasters@teaparty.net
Subject: Re: VMware SRM + NetApp SRA + NetApp WFA?

Hi Tim
Thanks for the speedy reply.

Forgive me, but I don't see source volume name, source aggregate name, source aggregate owner, or source intercluster LIF in the object properties that Get-NcSnapmirror returns. I'm sure I'm misunderstanding where you're going with it. I don't see how I would get that information at all, just given the input parameters of current destination cluster mgmt, current destination vserver, and current destination volume.

The reason I'd like to get the source cluster management hostname out of this is so I can Connect-NcController to it, then run Get-NcSnapmirrorDestination against it to verify that both sides of the Snapmirror relationship agree upon the state of things before proceeding. Then, I'd run Remove-NcSnapmirror against the current destination, then Invoke-NcSnapmirrorRelease against the current source, then New-NcSnapmirror against the current source to turn it into the destination side, then Invoke-NcSnapmirrorResync against the current source to actually do the reverse resync.

I know all of this works, because when I manually feed my script the information I am trying to programmatically get, it succeeds in both directions, and I can flip flop all day. However, I want to reduce the number of human inputs as much as possible for this critical operation, and the more that can be determined by a machine instead of a stupid human, the better :)


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948 / ian.ehrenwald@hbgusa.com


________________________________________
From: tmac <tmacmd@gmail.com>
Sent: Wednesday, January 3, 2018 11:30:00 AM
To: Ehrenwald, Ian
Cc: toasters@teaparty.net
Subject: Re: VMware SRM + NetApp SRA + NetApp WFA?

I don't think you will be getting that the way you think.

SnapMirror in Clustered ONTAP is vastly different.
For starters, you are supposed to have at least one Intercluster LIF per node.
This is because when SnapMirror kicks off, it will use the InterCluster LIF on the node that the volume actually resides.

If you do a "vol move" from node 1 to node, the next time, SnapMirror will use the InterCluster LIF on node 2.

Same idea goes for the destination IP. It will go to where ever the volume/aggregate resides.

To get the source address, you will need to do some calculations:
source volume name -> aggregate name -> aggregate owner -> intercluster LIF on node owner.
That would be your source address. Again, if the volume changes nodes, then the source address will change!


--tmac

Tim McCarthy, Principal Consultant

Proud Member of the #NetAppATeam<https://twitter.com/NetAppATeam>

I Blog at TMACsRack<https://tmacsrack.wordpress.com/>


On Wed, Jan 3, 2018 at 11:11 AM, Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.com<mailto:Ian.Ehrenwald@hbgusa.com>> wrote:
I've been working on this off and on between my regular duties, then delayed by holiday breaks, etc.

Something I haven't been able to figure out is how to programmatically get a Snapmirror relationship's source cluster management address hostname (or even just an IP address). I can easily get the source vserver name, source volume name, and even a pre-constructed combination of the two from what Get-NcSnapmirror returns when run against the destination controller.

In essence, I want to be able to pass to this script three arguments: Current Snapmirror destination cluster mgmt address, current snapmirror destination vserver, and current Snapmirror destination volume. Then do some stuff to extract the rest of the required information out to reverse the relationship and resync, such as current snapmirror source cluster address, current snapmirror source vserver, and current snapmirror source volume. I'm 66% of the way there, it's the current snapmirror source cluster address that I can't see to pull out of anywhere.

I was playing around with Get-NcVserverPeer when run against a Snapmirror destination, but I can't seem to get what I want there.

Any hints from people who have done this before? Thanks so much.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948<tel:1.617.263.1948> / ian.ehrenwald@hbgusa.com<mailto:ian.ehrenwald@hbgusa.com>


________________________________________
From: Ehrenwald, Ian
Sent: Thursday, December 14, 2017 11:40:41 AM
To: toasters@teaparty.net<mailto:toasters@teaparty.net>
Subject: VMware SRM + NetApp SRA + NetApp WFA?

This isn't 100% NetApp related, more like 60%, but I think it's still a relevant topic of discussion that others may eventually benefit from too.

I've been tasked with setting up DR for a set of VMware VMs at our primary data center by replicating them via SnapMirror to our secondary data center. Normally I'd just use VMware SRM with the NetApp SRA, set up Array Based Replication within SRM, and be done with it. Let SRM and the SRA take care of test, failover, reprotect, etc.

However, the sticking point is that a lot of the protected VMs use in-guest NFS mounts for things like database volumes or application binaries and SRM doesn't know what to do with those SnapMirror pair volumes because they're not VMware datastores.

My initial thought was to use some PowerShell with the NetApp PowerShell Toolkit in the SRM Recovery Plan for each individual VM pre-boot to connect to the SnapMirror destination filer, break the SnapMirror(s) that the VM uses, mount the volume(s), set export policies, etc. Then figure out how to correctly do resync and reprotect without blowing things up.

I got as far as the first part in PowerShell (connect to the destination filer, break the mirror) and thought to myself that this was stupid.. I'm re-inventing the wheel. Surely someone else out there must have done this before and there is a pre-existing solution? I spoke with a NetApp tech support engineer that I happened to have a case open with already regarding the NetApp SRA and he was able to come up with a suggestion from another engineer: Call WFA from SRM in each VMs recovery plan to break the SnapMirror for the volumes required for the VM to work, then also use WFA in the cleanup and reprotect plan to do that work.

Has anyone else done something like this? I have a feeling that I'm not breaking new ground with this task. Implementing it wrong has pretty severe implications, though, so I'm not eager to mess it up.


Ian Ehrenwald
Senior Infrastructure Engineer
Hachette Book Group, Inc.
1.617.263.1948<tel:1.617.263.1948> / ian.ehrenwald@hbgusa.com<mailto:ian.ehrenwald@hbgusa.com>

This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net<mailto:Toasters@teaparty.net>
http://www.teaparty.net/mailman/listinfo/toasters<http://www.teaparty.net/mailman/listinfo/toasters>

This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

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?

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.

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

"then once you find the destination"
This is the part that is in question -
Given a cluster and volume how do you find the cluster/SVM management address of the mirror/vault source/destination.
You can easily get the cluster and SVM name, but those don't translate to the management addresses.
As Tim said, you can get the ICL addresses from the peering relationship but I haven't found anything that will return the management address for a given peer cluster/SVM.

In our case, all our clusters have a uniform relationship between cluster name and management address so I can work around it - but I couldn't assume that for any other environment.

m

-----Original Message-----
From: John Stoffel [mailto:john@stoffel.org]
Sent: Wednesday, January 3, 2018 3:53 PM
To: Weber, Mark A <mark-a-weber@uiowa.edu>
Cc: Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.com>; toasters@teaparty.net
Subject: RE: VMware SRM + NetApp SRA + NetApp WFA?


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?

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.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters

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.

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters