Hi all, I have run into a cross-vendor concern with IscsiStorageCleanupMonitor that I’d like the list’s input on. Two parts — one is an operational question, the other is a specific diagnosis.
*1. How widely is the monitor enabled?* How commonly do production deployments set iscsi.session.cleanup.enabled=true in agent.properties (default: false)? The intent is clear — periodically scan /dev/disk/by-path/ and release iSCSI sessions whose devices are no longer referenced by any running VM, so sessions left behind by crashed or forcibly-stopped guests get reclaimed. Before proposing a change I’d like to understand how widely this is actually turned on in practice. Opt-in diagnostic? Routine production hygiene? *2. The path-matching concern* When the flag is on, IscsiStorageCleanupMonitor decides whether a session is “stale” by comparing the entries it collects from /dev/disk/by-path/* against the paths it finds in running VMs’ libvirt XML. The compare is a bare String.equals via diskStatusMap.containsKey(disk.getDiskPath()) in updateDiskStatusMapWithInactiveIscsiSessions. The problem is that udev creates several symlinks for the same device, and different adaptors put different forms into libvirt XML. udev produces all of these simultaneously: /dev/disk/by-id/scsi-3600a098078304d2d383f2f6b45734c6a /dev/disk/by-id/wwn-0x600a098078304d2d383f2f6b45734c6a /dev/disk/by-id/scsi-2600a098078304d2d383f2f6b45734c6a /dev/disk/by-path/ip-10.0.0.1:3260-iscsi-iqn.1992-08... IscsiAdmStorageAdaptor bakes the by-path form into libvirt XML. Other adapters can bake the by-id/wwn-0x form or other form — identity-stable across hosts. Because the monitor only matches by-path strings: - disk.getDiskPath() for a VM created using IscsiAdmStorageAdaptor is /dev/disk/by-path/ip-…-iscsi-…-lun-N → direct hit in the map, correctly marked *active*. - disk.getDiskPath() for an VM created by other adapter(For e.g Netapp, FiberChannel) is /dev/disk/by-id/wwn-0x600a0980… → never matches the by-path keys, stays marked *inactive* despite the LUN being in use. In disconnectInactiveSessions the still-inactive entries get passed to the pool manager’s disconnectPhysicalDiskByPath iteration. IscsiAdmStorageAdaptor.disconnectPhysicalDiskByPath claims it — its match is a -iscsi- substring check with no vendor filter — and runs iscsiadm --logout . *If multiple VM share the same iscsi session , all other VMs lun get logged out. * *MultipathSCSIAdapterBase already handles this correctly* For comparison, the FC path’s MultipathSCSIAdapterBase.disconnectPhysicalDiskByPath filters by both path prefix (/dev/mapper/) and an explicit SUPPORTED_OUI_LIST (currently 0002ac HPE 3PAR, 24a937 Pure). An ONTAP WWID starting with 00a098 would be correctly declined. That’s the pattern the iSCSI side needs. Thanks, Piyush
