topic Re: SVM migrate to new node in ONTAP Discussions

SVM migrate to new node

JohnOBrien — Wed, 04 Jun 2025 14:45:59 GMT

HI All,

Is there any facility in ONTAP that allows the movement of an SVM from one node to another within the same cluster?

I have considered SVM-DR but this requires the destination SVM to have a different name, which I would like to avoid.

Thanks,

John

Re: SVM migrate to new node

aborzenkov — Fri, 04 Aug 2017 06:29:16 GMT

SVM is logical collection of resources; it is not associated with any specific node.

Re: SVM migrate to new node

TMADOCTHOMAS — Fri, 04 Aug 2017 13:03:43 GMT

That's right, you might just be trying to move the volumes in an SVM to a different node. You can do that non-disruptively with the volume move start command, or by right-clicking in System Manager and choosing Move. The only disruption would be a brief one for volumes used in a CIFS server during cutover.

Re: SVM migrate to new node

JohnOBrien — Mon, 14 Aug 2017 14:06:12 GMT

Thanks guys,

Are there any considerations for the root volume of the SVM?

The current nodes holding the svm root volume will be removed from the cluster.

Thanks again,

John

Re: SVM migrate to new node

colsen — Mon, 14 Aug 2017 17:50:45 GMT

There aren't any special considerations per se for the root volume other than availability and proximity to your data volumes. If you have a aggregate that's prone to going inconsistent or in danger of filling up, you probably don't want to put your SVM root there because your namespace/junction path for the SVM will go offline when you lose access to the aggregate. Figure out what node/aggregate is going to store the data volumes and co-locate your root with them. Then you can retire the nodes/aggregates that currently host the SVM root volume without disruption.

There's lots of healthy debate out there about indirect I/O (i.e. the LIF serving the data isn't on the node/aggregate hosting the data - data traffic crosses the cluster network) but rather than getting into that whole can of worms, make sure you relocate your data LIF off to the node/aggregate you're moving the data to as well. Don't want to get everything migrated over to other nodes in your cluster and then shut down the HA pair that hosts your LIF. All operations have proven to be non-disruptive for us (pay attention to the previous poster concerning CIFS).

Good luck!

Chris

Re: SVM migrate to new node

TMADOCTHOMAS — Wed, 16 Aug 2017 12:52:37 GMT

One other comment on root volumes - they can be moved just like any other volume without issue. I've moved my root volumes several times to different aggregates with no ill effects.

Re: SVM migrate to new node

Sant — Fri, 03 Aug 2018 19:14:13 GMT

Hi Chris,

Regarding indirect traffic, If I migrate my LIFs to other nodes which will be present in cluster (one apart from target decommission) will there be any disonnects or umnounts to my VMDKs?

I have alredy moved the data volumes off from target decommision nodes, I need to migrate the SVM roots out from it and thinking to move the LIFs as well to corrosponding nodes.

I'm using OMTAP 9.1P8 version with FAS 8080 in 12 node multi-protocol cluster.

Regards,

Sagar Sant

Re: SVM migrate to new node

AlexDawson — Mon, 06 Aug 2018 06:11:46 GMT

Hi there @Sant,

If you're using NFS, or iSCSI it should be seamless - it is designed to work like this, but you should always test first with low criticality systems, in case of network device configuration problems.

Re: SVM migrate to new node

Sant — Mon, 06 Aug 2018 23:26:53 GMT

Thanks for reply Alex.

so, should I migrate the LIFs and the root volumes? I have never done this before and want to make sure I'm not hitting anything bad on production systems.

Regards,
Sagar Sant

Re: SVM migrate to new node

AlexDawson — Wed, 08 Aug 2018 03:35:45 GMT

NFS LIFs would need to be migrated, ISCSI LIFs cannot be migrated - you will need to take them offline, but access should continue over the new LIFs due to ALUA.

If you have not tested this functionality inside your environment, I cannot give you assurances that this will be non-disruptive, as it requires network connectivity to be correct, but it usually is - your best course of action would be to setup a test SVM, with new LIFs on both the old and new nodes, create a new datastore and map it, then test the activity with that.

Yes, SVM root volumes will need to be moved to surviving nodes, and this will be non-disruptive.

Hope this helps!