topic Re: Changing IP on primary host cause failed in Active IQ Unified Manager Discussions

Changing IP on primary host cause failed

BRIANLIU11 — Thu, 05 Jun 2025 06:17:48 GMT

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

Re: Changing IP on primary host cause failed

adaikkap — Mon, 08 Oct 2012 06:21:05 GMT

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 ?

Regards

adai

Re: Changing IP on primary host cause failed

BRIANLIU11 — Tue, 09 Oct 2012 04:37:18 GMT

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 0819DIP000SF001.detnsw.win:E:\ 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*>

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

Snapvault is ON.

Source Destination State Lag Status

0819DIP000SF001.detnsw.win:E:\ NASHE01:/vol/s0819DIP000SF001/Exx Snapvaulted 188:32:27 Idle

NASHE01*>

Relationship on DFM

--------------

2818 snapvault

684 ds005

0819DIP000SF001:E:/

NASHE01:/s0819DIP000SF001/Exx

Re: Changing IP on primary host cause failed

BRIANLIU11 — Wed, 10 Oct 2012 02:05:24 GMT

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.

Re: Changing IP on primary host cause failed

adaikkap — Wed, 10 Oct 2012 08:54:24 GMT

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

Regards

adai

Re: Changing IP on primary host cause failed

mital_shah — Sun, 23 Dec 2012 13:14:00 GMT

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: https://kb.netapp.com/support/index?page=content&id=2015803

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.