Hello, I am in the process of retiring heads in my cluster.
I have relocated all luns to the new nodes, connections established and the only thing remaining is the initiator interface on the old nodes. The problem is that I am unable to disconnect the session at the host from the old nodes on some systems (various windows versions). For some reason, it is demanding that there are active luns (even though none are being hosted there). Forcing the issue by taking the filer nic offline and disconnecting from the host only causes a loss of disk that needs to be put back in place which causes an outage. I am confused as to why this is happening as it is counter ALUA laws. Is there some workaround that I could do this non-disruptively? I have tried reboots etc to no avail. Code 9.7P16
Here by 'nodes' & 'cluster' you mean the - Host side (Windows) ? So, you are trying to disconnect the iSCSI sessions from the retired windows-hosts ? Any screenshot of the error you could share.
nodes=nodes in the c-dot cluster
In the screenshot, 10.68.171.121 has no luns running on that node, so there should be no problem removing it, yet the windows system is insistent that it is controlling at least one of them. I can rip it out from the filer side, but the windows system will drop its connection. The only recovery for that it is to remap it. The ONLY thing running on 10.68.171.121 node is networking, all aggregates are gone. Also, most systems are fine and only a handful give me this problem (multiple versions of windows).
From the screenshot it looks like a 'SnapDrive for Windows' is in use? it's no longer supported (Only specific bundled versions for older ONTAP). You mentioned ONTAP 9.7, what applications are you using for ? Just fyi: SDW isn't supported since ONTAP 9.4 (only bundled suits). Officially you will not be able to raise a ticket.
In any case:
1) Is anti-virus running on the Windows host? Try stopping it.
2) Try stopping 'windows backup' service in services.msc
Thanks, I am aware that it is no longer supported and our newer systems are no longer using it. Regardless, I have uninstalled SDW on another system already and had the same issue. I don't think they use backup service but will try to disable AV.
I cannot distinguish which disk it is insisting it is until I rip it out by offlining the iscsi nic on the filer and then disconnect the session. At that point the lun (not all of them) will dissappear and not able to connect again until I unmap all connections on the filer side and then start fresh connect for all luns.
Can you verify the list of reporting-node for the lun mapped (the one that were relocated).
You can check by running the below command:
cluster::> lun mapping show -fields reporting-nodes
if the luns still showing the previous node, proceed and remove those entries and add the new nodes:
cluster::> lun mapping remove-reporting-nodes -vserver <vserver name> -path <lun path> -igroup <igroup name>
cluster::> lun mapping add-reporting-nodes -vserver <vserver name> -path <lun path> -igroup <igroup name>
Once this has been corrected, re-attempt the disconnect within Snapdrive.
NetApp Wins One Silver and One Bronze Stevie® Award in 2022 Stevie Awards for Sales and Customer Service