#Use command "net int migrate" to migrate LIF to the other mode for "direct connect"?

1 messages · Page 1 of 1 (latest)

raven mantle
#

Let's say I have a dedicated LIF for a specific Datastore, in order to have "direct connect", in stead of "vol move" the volume which I usually do, can I use the command "net int migrate" to migrate the LIF to the other node where the volume is located? and why? Thank you in advance.

vocal nest
#

first you modify the the new node and then you revert it:
network interface modify -vserver <SVM> -lif <LIF> -home-node <NODE>
network interface revert -vserver <SVM> -lif <LIF>

cold galleon
#

From my experience the migrate will have minimal impact. You will maybe loose 1-2 pings.

icy agate
#

Pretty sure if the -auto-revert is set to true, then when you change the home-node and/or home-port it will automatically go to the new location

raven mantle
#

My question is mainly about the command "net int migrate", not about how we should rehome the LIF.
I understand "net int migrate" SHOULD be able to migrate the LIF to the other node. But, with a number of VM's running on the Datastore, if it could cause any issues to do that?

brazen tulip
#

it's not a problem in 99.9% of cases... just reasign the -home-node (and probably -home-port) and run net int revert * and it'll move and there'll be a few packets dropped... this happens also with every upgrade and as long as your net isnt't generally broken (arp works), it just works

raven mantle
#

Why would have to reassign the home-node and net int revert? I understand this way will migrate the LIF to the other node. But, shouldn’t “net int migrate “ alone should do the same without rehome? I understand it will not change the LIF’s home-node.

timid wing
#

for example: because it might auto-revert back when you don't expect it, and because ONTAP updates will not be possible unless all ports are on their home-node and home-port

#

also it will show red warnings in System Manager (in case you use that to manage the system)

raven mantle
#

Understand why I need to rehome. So, are you guys saying in addition to “net int migrate”, I also need to run rehome, right?

timid wing
#

yup. migrate and then modify home-node/home-port on the lif. Or: modify home-node and home-port first, and then "revert"

raven mantle
#

Thanks. Now, back to the other point, to move a volume or a datastore, i usually use “ volume move”. However, in this case, since the LIF is dedicated to the volume, I can use “net int migrate “ which is much faster only take a second. Therefore, can I say the later method is better and it can justify why we need to assign a dedicated LIF to a datastore?

timid wing
#

I don't think I understand that question. These two commands do very different things. One moves a LIF (the IP address), the other moves data (the volume) to a different aggregate. And yes, one is faster than the other, but again these are different things you're moving?

#

but in general, yes, in larger environments, it is a good idea to use a dedicated IP address for every datastore and mount through that

analog cipher
#

And make sure that in normal operation, the aggregate and lif are on the same node. This gives optimal performance

raven mantle
#

@timid wing
Let's say, I use "vol move" to move a volume to nodeA where the volume is located. Alternatively, I can also use "net int migrate" to move LIF to nodeA which can also have clients to directly access the volume. Two methods will result in the same, but 2nd method should be faster and better. Is my understanding correct?

timid wing
#

um not sure I follow. if you have the volume on nodeA and the LIF on node B, the two alternatives discussed are not the same: you either end up with both volume + LIF on node A, or you end up with both on node B. Depending on other load on the nodes, the result might be very different.
If you just want to have the LIF and the volume on the same node and don't care about which node, then yes, both are "the same" and moving the LIF is faster. But again, it depends on the other load on the node and in some cases, moving the LIF can make access actually slower even though it's on the same node than the volume