Not sure about the detail steps taken while performing the vol move and add-reporting node. This article describes the procedure that should be followed to rescan and recover LUN paths in different Operating Systems (OS), while moving a LUN or a volume containing LUNs to another HA pair within the same cluster. Modify the Selective LUN Map (SLM) reporting-nodes list, before initiating the move (add-reporting-nodes) and after the move is completed (remove-reporting-nodes).
The procedure below ensures that active or optimized LUN paths are maintained in the host OS multipathing.
RE: "Not sure about the detail steps taken while performing the vol move and add-reporting node"
NO volume moves had been attempted. This was preparation for the moves.
None of the NetApp documentation (that we could find) says anything about the process of adding reporting nodes as being disruptive. And from what myself and my colleagues saw, the process of adding reporting nodes did not disrupt the initiator to target iscsi connections, but the disk mount in the Windows server was dropped. I notice that the title of the link you provided contains the term "recover LUN paths". Could this be an indicator that the add-reporting-nodes process affects the LUN paths?
Hi again @hmoubara RE: "any errors seen on the host side or a rescan that was performed "
The customer did not report any errors other than the fact that the Windows mapped drive (which was via iscsi) disappeared. The disk reappeared after a rescan. And unfortunately we don't have access to the servers on the customer prem.
Hello @paul_stejskal RE: "add the targets or confirm the targets IPs were added to the Windows server ok"
The targets and IPs (pathways) were all functional up to the 'add-reporting-nodes' and even still existed after the command was run on all the LUNs. It was just the disk mapping in the Windows servers that disappeared. BTW: the iscsi connections are all legacy and were not set up by us.