OK, issue solved. Sort of. Here's what happens: - Target moves from one cluster node to another. - Windows iSCSI initiator reconnects to target. - Immediately after login, iSCSI initiator issues REPORT LUNs. - Then for every LUN, iSCSI initiator issues INQUIRY for VPN pages 0x80 and 0x83. - If the device ID or serial number of _any_ device do not match what the iSCSI initiator has cached, then it does a REPORT LUNs again, and not only INQUIRY on every LU, but also Read Capacity, Mode Sense, etc. It just does a full bus rescan. Now, I had thought of using explicitly defined scsi_id and scsi_sn for all my LUs. What I hadn't thought of is that the Windows iSCSI initiator also looks at LUN 0, and that LU I can't modify in STGT. Thus, I can't set a custom serial number. And if the target ID happens to change on failover, then the serial number of the "controller" LU changes and Windows gets horribly confused. IET doesn't have this issue simply because there LUN 0 is a regular disk LU. I guess I'll work around this in my Pacemaker RA, but would it be a huge problem if you could make the SCSI SN and SCSI ID of the "controller" LU configurable from userland, just like for regular disk LUs? Cheers, Florian
Attachment:
signature.asc
Description: OpenPGP digital signature
