nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Question about Fibre Channel pathing and migrating LUNs

HUX20002000

I have an older NetApp and I recently added a new one to the cluster. Both are connected to a pair of Fibre Channel (FC) switches. When connecting the new system, I added its WWPNs to all the zones on the FC switches. (Both NetApps are also connected to a pair of cluster switches.) Meanwhile, I have a bunch of VMware ESXi hosts connected to the same pair of FC switches. With this all set up and ready to go, I migrated the LUNs from the older NetApp to the new (using "volume move start ..."). All good so far.

Then I noticed something strange in vCenter: when looking at the paths for the LUNs, it only shows the WWPNs for the old NetApp. My assumption, therefore, is that the hosts are accessing the LUNs indirectly, via the cluster switch network. That's not good.

As a test, I created a new LUN on the new NetApp and connected it to the hosts. But this time, vCenter shows the WWPNs for the new nodes, as expected.

What's going on here? Is there something I need to do to give the LUNs a kick, so they start using the new paths? (Maybe I need to unmount them from the hosts and remount them?) Also, if I do nothing, will they automatically start using the new paths when I eventually shut down the old NetApp?

Find more posts tagged with

Accepted answers

Abeltran

Hello HUX20002000,

Maybe the reporting nodes from the lun mapping are not updated with the new nodes and you have to add them manually.

Take a look at:

https://docs.netapp.com/us-en/ontap/san-admin/selective-lun-map-concept.html#determine-whether-slm-is-enabled-on-a-lun-map

Kind regards,

Albert

All comments

Abeltran

Hello HUX20002000,

Maybe the reporting nodes from the lun mapping are not updated with the new nodes and you have to add them manually.

Take a look at:

https://docs.netapp.com/us-en/ontap/san-admin/selective-lun-map-concept.html#determine-whether-slm-is-enabled-on-a-lun-map

Kind regards,

Albert

TMACMD

I see a couple of things here

did you create NEW LIFs for fc for the new nodes?
Do you use portsets

as was infected, find out if you are using slm. This allows ONTAP to advertise paths automatically from the node with the lun plus its ha partner

more importantly did you create new luns? if you simply added the WWPNs of the hardware (50:00:xx..etc) that is another reason it’s not working.

ONTAP never uses the hardware WWPNs for serving data. You must create the logical fcp lifs and update the zone configuration

jaikumar

Assuming the configuration is a 4 node or more node cluster. Say for example, the cluster is like n1,n2,n3,n4. with n1 and n2 being the old nodes and n3 and n4 new nodes.

vol move start from aggregate in n1/n2 to n3/n4 will check for the fcp lifs on new nodes (n3 and n4).
As part of the vol move, the lun mapping will automatically add n3 and n4 as the reporting nodes. there is no user intervention required here.
So most likely the cause of the problem is
***** The fcp lif have not logged in from the host. So use the command fcp initiator show (diag level priv) to check if the host initiators are logged in via node n3 and n4.
****** The rescan for new paths are not performed on the ESX host (but this is least likely as the ESX does SCSI bus rescan at freq. interval).
-----

Note:
After the vol move is completed check for the following,

The lun have 3 Active Non-Optimized Path (from VSphere) and 1 Active Optimized Path
The initiator is logged in via all the fcp lifs on the Node.

--------

For the Other Questions,

is that the hosts are accessing the LUNs indirectly, via the cluster switch network --> Yes it will access if the IO path to the LUN from the LUN owning node is not accessible.
Is there something I need to do to give the LUNs a kick, so they start using the new paths? --> No Not Required, SCSI Host Stack must take care of it automatically as long as there are IO path to the LUN.
if I do nothing, will they automatically start using the new paths when I eventually shut down the old NetApp? --> No,you shouldn't shut down the old nodes till the new Path from the New Nodes are discovered. So before you bring down the old node,
- IO Path from LUN owning Node and its HA Pair is Discovered (VSphere)
- Confirm IO is happening via the lun owning node (ONTAP)
- Bring down the LIFs from Old node one after another and ensure IO is not disrupted.
- After the LIFs are brought Down, use lun mapping remove-reporting-nodes -vserver <vserver name> -path <lun path> -remote-nodes true

Jai/

HUX20002000

Thank you! This was the issue and I figured out the solution based on the info at that link. The process is straightforward and is done on a per-LUN basis:

1) In NetApp, add mapping to new nodes:

lun mapping add-reporting-nodes -vserver [SVM] -path [LUN path] -igroup * -local-nodes true

2) In vCenter, confirm new paths are visible, with correct I/O

3) In NetApp, remove mapping from old nodes:

lun mapping remove-reporting-nodes -vserver [SVM] -igroup * -path [LUN path] -remote-nodes true

4) In vCenter, confirm old paths show as "Dead"

5) In vCenter, refresh storage on host and confirm that old paths are gone