[Bug 2166370] Re: [NetApp] get_iscsi_target_details() does not paginate iscsi-interface-get-iter, causing iSCSI LIFs to be silently dropped and volume attach failures with SLM

** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** No longer affects: kernel-sru-workflow ** No longer affects: kernel-sru-workflow/abi-testing -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2166370 Title: [NetApp] get_iscsi_target_details() does not paginate iscsi-interface- get-iter, causing iSCSI LIFs to be silently dropped and volume attach failures with SLM Status in linux package in Ubuntu: New Bug description: Summary A customer running a NetApp ONTAP backend and Selective LUN Mapping (SLM) enabled found that attaching a Cinder volume to a Nova instance consistently failed.the volume sat in "attaching" status for about 7 minutes, then reverted to "available". Investigation traced this to Client.get_iscsi_target_details() issuing a single iscsi-interface-get-iter ZAPI call without a max-records argument and without any pagination handling. When an ONTAP cluster has more iSCSI LIFs than fit in one default-sized ZAPI response page, the method silently returns only the first page of results. Because SLM restricted the affected LUN to specific reporting nodes whose LIFs fell outside that truncated first page, those LIFs were never returned to Nova/os-brick, the initiator never attempted iSCSI login/discovery against them, no working path was created, multipath -ll showed no device, and the attach ultimately timed out and rolled the instance back to available. Environment - OpenStack: Nova + Cinder (NetApp cDOT iSCSI driver), os-brick iSCSI connector - Backend: NetApp ONTAP cluster with 12 nodes, SLM (Selective LUN Mapping) enabled - Multiple nodes/LIFs in the cluster (>20 iSCSI interfaces total) Steps to reproduce / conditions 1. Configure an ONTAP cluster with enough nodes/iSCSI LIFs that the total LIF count exceeds ONTAP's default iscsi-interface-get-iter page size when max-records is not specified. 2. Provision a LUN whose SLM reporting-nodes are configured such that the serving LIFs are not in the first page of results returned by an unpaginated iscsi-interface-get-iter (in the customer's case, node 05/06 LIFs were excluded while nodes served by the LUN's home controller happened to fall outside the returned page). 3. Attach the corresponding Cinder volume to a Nova instance Observed behavior - nova-compute logs "Attaching volume ... to /dev/sdb", passes connection info (target_portals/target_iqns/target_luns) to os-brick. - os-brick's iSCSI connector logs in to the portals it was given and repeatedly scans for the device (Searching for a device in session ... yield: None) in a loop for ~7 minutes. - Packet capture confirms no iSCSI login/REPORT LUNS traffic is ever sent to the target IPs on the controller nodes (05/06) that SLM actually maps the LUN to - Manual LUN mapping test on a second compute node (comp138) confirmed the LUN is correctly reachable there because that host happened to already have a session on a portal within the returned page. - Attach ultimately fails: os_brick.exception.VolumeDeviceNotFound: Volume device not found, and the volume reverts from attaching to available. Root cause: get_iscsi_target_details() in client_cmode.py does not set max-records on the iscsi-interface-get-iter request and does not iterate using the next-tag element ONTAP returns when a result set is truncated. With enough total iSCSI LIFs across the cluster, the call returns only a partial (first-page) list of LIFs. When SLM restricts a given LUN to specific reporting nodes whose LIFs are not in that truncated first page, the Cinder driver never advertises those LIFs as target portals, so the initiator has no way to discover/log in to the correct path, and the volume attach fails. Impact: Any deployment with more iSCSI LIFs than one ZAPI page (commonly seen in larger/multi-node clusters) combined with SLM restricting a LUN to specific nodes can hit this - the driver may simply never learn about the LIFs it needs to advertise, causing intermittent, host/LUN-mapping-dependent attach failures that are difficult to diagnose without a packet capture, as seen here. [1] cinder/volume/drivers/netapp/dataontap/client/client_cmode.py -- swm properties -- built: route-entry: 1 reason: crank-failure: Stalled -- Package not identified from title ~~: tracker: last-message: '2026-09-03 14:45:14.345120+00:00' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2166370/+subscriptions