Snapmirror resync fails on two different simulator versions

[ss20040163CC]

Hi,

I've tried this on two different versions of the simulator (7.3.2 and 7.2.3).

netapp1 vol2 >> Snapmirrored to netapp2 vol2

Mirror configures okay, and can be quiesced fine (from Destination side). However, when I break the mirror (again from the destination side), and try to resync it fails with the following error:

Source Side:

netapp1> Thu Feb  4 16:57:41 GMT [snapmirror.src.resync.toSelf:error]: SnapMirror cannot resync volume vol2 to itself, operation not permitted.

Destination Side

netapp2> snapmirror resync vol2

Thu Feb  4 16:57:41 GMT [snapmirror.dst.resync.failed:error]: SnapMirror resync of vol2 to netapp1:vol2 : request refused by source filer; check configuration on source.
Snapmirror resynchronization of vol2 to netapp1:vol2 : request refused by source filer; check configuration on source
Aborting resync.

Host resolution is fine, /etc/snapmirror.conf from dest side is:

netapp2> rdfile /etc/snapmirror.conf
netapp1:vol2 netapp2:vol2 - * * * *

Thoughts appreciated.

What's more annoying is that a colleague can make this work between two different simulator versions....

Regards

Scott.

[shubhada]

Hi,

The destination volume must run under a major version of Data ONTAP the same as or later than that of the SnapMirror source volume; running different minor versions is allowed.

In your case,simulator running with 7.2.3 cannot be used as destination.It can be anything 7.3.x....or your source can be running with any 7.2.x

Can you check if this is the issue.

-Shubhada

[scottgelb]

I have seen the same issue... the ONTAP versions are the same since it's the simulator...when I install 2 instances of the same 7.3.2 sim in the linux image, I can mirror from nodeA to nodeB.  Breaking the mirror then resyncing back from nodeB to nodeA does not work and gives the same error you saw. ... even when the network is available, and snapmirror.access is set to *.  It think I first saw this issue in the 7.3.1 sim...hopefully it gets resolved in a future 7.3.x sim.  I haven't tested in the 8.0 7-mode sim yet...that will require 2 VMs since it's a single ontap sim per VM.

[ss20040163CC]

I've not tried the 8.0 version of the sim, but it seems theres an issue  that's easily repeatable.

Just need someone to make sense of the logs now!

Thanks for the replies.

Rgds.

Scott.

[ss20040163CC]

The ONTAP versions were the same:

7.3.2 >> 7.3.2

and then tested on

7.2.3 >> 7.2.3

Both gave the same errors on a resync command (both from the GUI - console flagged up the errors, and when resync from command line).

[shubhada]

Can you have different names for the source and destination volumes and try.

This scenario happens if in snapmirror.conf file source filer and dst filer are the same.

Also,NVRAM no of source and dst host might be the same as you are using simulator.Inthat case you will not hit this issue on a real filer.

-Shubhada

[ss20040163CC]

On 7.3.2 Test Filers were called "netapp3" and "netapp4"

On 7.2.3 Test filers were called "netapp1" and "netapp2"

Both tests failed on a resync with the same error.

[danielpr]

Some check list

* Ideally you should keep both the volume in same size. 

* Check if you have snapmirror access permitted for the re-sync.

* Look into Snapmirror.log for more details, it will help you to troubleshoot more.

Thanks

Daniel

[ss20040163CC]

This is the answer!

I created another pair of filers, this time on 7.3.0 Code. With snapmirror in place and running, the same error occured.

However, when I snapmirrored a pair of volumes (flex vols) with different names it works fine (initialize, quiesce, break, resync)

So to recap:

Environment:

netapp1:vol1 >>>> netapp2:vol1 (can initialize, quiesce, break, but on resync command "snapmirror resync vol1" it fails)

netapp1:apples >>>>> netapp2:oranges (can initialize, quiesce, break, and resync on "snapmirror resync oranges" command)

Therefore I can only conclude that Snapmirror resync command does something with the volume name, and trips up when it sees the same volume name on the source box.

Is there something in the snapmirror documentation that indicates source and destination volumes need to be called something different for snapmirror to work?

P.S I've tried this on a number of simulator versions now (7.2.3 / 7.3.0 & 7.3.2), and mixed snapmirror between versions (low to high) and it all does the same.

[pash_hrnic]

THANK YOU!

I've been breaking my teeth on this for the past day or so.  Initially in the log I was seeing:

src Wed Mar 24 10:09:03 EST sim3:vol2 sim1:vol2 Abort (resync to self not allowed)

...after changing the name on the dst filer

src Wed Mar 24 10:21:27 EST sim3:oranges sim1:vol2 Start
.

.
src Wed Mar 24 10:21:33 EST sim3:oranges sim1:vol2 End (92 KB)

...and now snapmirror status reports:

sim3:oranges          sim1:vol2             Source         00:10:03   Idle

[shubhada]

Nice that using different vol names worked for you.I don't find any such thing documented for resync to work.Also,we have not seen this issue on real filers.Will update if this is reproduced and something else is known on this.

-Shubhada

[scottgelb]

When I do a vfiler dr resync ... (multistore requires volume names the same on source/target) then it seems to work just fine... only when running the resync command from snapmirror, but doesn't look like an issue when done from a vfiler context... odd... simulator only bug is the good news.

[ashley_thrift]

I had a similar issue with two simulators, both on 7.3.0

Simply changing the dest vol name fixed it -- thanks, guys!

Just wondering, does this issue only affect sims, or real systems too?

I thought I'd done successful resyncs in the past with volumes that were the same name... but its been so long, i'm not sure.

TIA.

-A-

[pash_hrnic]

simulator only bug

[vtspnvgwest]

Just edit the ,serial file in the simulator directory. Make sure that the destination filer serialno has another one than the source filer. problem solved 🙂