Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
LUN presented from one aggregate not showing on a Windows Server 2019 host.
2021-09-14
07:07 AM
5,525 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a Windows Server 2019 host that has multiple luns presented from our NetApp, spanning 3 different aggregates. When I create a new lun on the recently created 3rd lun, and add it to the proper initiator group, it never appears on the server. I can create luns on the other 2 aggregates and even move the lun from the 3rd aggregate to one of the other 2, and the lun appears on the host with no issues. I have tried adding the luns to multiple servers with different windows versions to be sure that it wasn't something like a recent update.
Is there something that maybe got missed during the aggregate creation? Any help would be appreciated.
Solved! See The Solution
1 ACCEPTED SOLUTION
ChristopherMCO has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you both! After racking my brains for the last 2 days, I decided to take a small outage (it's a UAT server I was working with), and removed all the targets for all 6 nodes from the host server and re-added them. Apparently, it must have been sitting there in a "false connected" state. After reconnecting all the targets, the newly created luns showed up.
7 REPLIES 7
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
what's your ONTAP version?
how many node on your cluster?
all the aggregates are on the same node/HA-pair?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We're still on OC for this particular cluster, it has 6 nodes, and the aggregates are all on different nodes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this iscsi or fc? Did you check slm?
Sent from my iPhone
Sent from my iPhone
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is ISCSI.
When I check slm, the rest of the luns are reported from the same 2 nodes, but the new ones I create off this 3rd aggregate is reported from nodes different from the rest.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
so first I guess you got it right?
probably your server has iscsi sessions to the nodes where the "working" LUNs are
you must:
1 - modify SLM, or
2 - create new sessions to the nodes where the third aggr is
regarding the SLM config difference... it is a good question. I believe you created all the LUNs in the same way, same params, right (either via SysMgr or CLI)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As already suggested...
Curious as you mentioned "6" Node cluster, that suggests we have 3-HA Pairs. By default, only paths from the host to the Node containing the storage virtual machine (SVM) where the LUN was created, and paths to the HA partner of that node, are visible to the host. Could the "2 aggr" where LUNs are visible to Host are from same HA Pair, whereas the 3rd aggr is on a different Node (HA-PAIR) and does not have LIF on that Node ? Could you create 'iSCSI LIF' on the 3rd Node (HA-Pair) and try discover this 'LIF/IP as target' from Windows Host ?
ChristopherMCO has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you both! After racking my brains for the last 2 days, I decided to take a small outage (it's a UAT server I was working with), and removed all the targets for all 6 nodes from the host server and re-added them. Apparently, it must have been sitting there in a "false connected" state. After reconnecting all the targets, the newly created luns showed up.
