Community maintenance is complete. Thank you for your patience!

Active IQ Unified Manager Discussions

Changing IP on primary host cause failed


Hi there,

A few days ago a primary host's IP address was spotted changed on DFM (v5.1.0.15008 (5.1))which complaint this.

Under the suggestion the DB had been updated with the new IP but it didn’t work like that way. A recent job says "the qtree is not the source for the replication destination".

The DFM won't perform backup for this primary host after this. Can someone please advise of how to fix this? I wonder if doing a restart of DFM could possibly solve this issue.

Many thanks,

- Brian



Eventually we found that the server 0819DIP000SF001 is not the original one we've done the baseline.

Windows admin has made some changes to that primary. Thanks Adai. Please disregard this thread.


Thanks Brian. Its always helps to verify with Ontap to nail down the root cause.




Hi Brian,

     Can you try running an update from the controller and let us know what is the outcome ? Do you get the same error ?

Also you can give the output of snapvault status on the controller and dfpm relationship list output on dfm ?




snapvault update doesn't work on the controller. . See the message below,

NASHE01*> snapvault update NASHE01:/vol/s0819DIP000SF001/Exx

Tue Oct  9 15:32:03 EST [NASHE01: replication.dst.err:error]: SnapVault: destination transfer from\ to /vol/s0819DIP000SF001/Exx : the qtree is not the source for the replicati.

Transfer aborted: the qtree is not the source for the replication destination.


NASHE01*> snapvault status NASHE01:/vol/s0819DIP000SF001/Exx

Snapvault is ON.

Source                          Destination                        State          Lag        Status\  NASHE01:/vol/s0819DIP000SF001/Exx  Snapvaulted    188:32:27  Idle


Relationship on DFM


2818 snapvault               684 ds005            0819DIP000SF001:E:/                  NASHE01:/s0819DIP000SF001/Exx        No            


Not specificallly in response to your issue but regarding the same error, in case this helps anyone else out there.

Filer1> snapvault start -S Server1:/data1     Filer1:/vol/vol01/data1

Snapvault configuration for the qtree has been set.

Thu Dec 13 19:21:05 EAT [replication.dst.err:error]: SnapVault: destination transfer from Server1:/data1 to /vol/vol01/data1 : the qtree is not the source for the replication destination.

Transfer aborted: the qtree is not the source for the replication destination.

NetApp has a KB on this too, but it did not resolve my issue:

When I ran snapvault stop for a relationship, it confirms configuration removed, qtree deleted, but I still can't start a snapvault for the same qtree, with the error above. The NetApp KB says manually delete qtree, but in my case qtree didn't even exist, yet it didn't allow snapvault start. [I assume, even though it says qtree deleted, perhaps it still takes hours to actually delete it & exists in the background].

Only workaround I found was to use a different qtree name, e.g. /vol/vol01/data1_new I hoped it will allow me to rename the qtree once complete, but then I get the error:

qtree: could not rename /vol/vol01/data1_new to /vol/vol01/data1: Read-only file system - so I guess only solution is to change all scripts to use new name in our case.

NetApp on Discord Image

We're on Discord, are you?

Live Chat, Watch Parties, and More!

Explore Banner

Meet Explore, NetApp’s digital sales platform

Engage digitally throughout the sales process, from product discovery to configuration, and handle all your post-purchase needs.

NetApp Insights to Action
I2A Banner