>Yes, please. From the thread above, and from the ML archive, I can't >really tell just what the problem exactly is, and what the suggested >fix would be (granted, I may be missing some context). As far as i can >tell the RA already does the right thing by accepting a parameter >enabling users to persist scsi_sn. It also tries to generate a >suitable value for you by default, based on the Pacemaker resource ID. Done, https://github.com/ClusterLabs/resource-agents/issues/726 > >Additional insight would be appreciated. > It's possible that others haven't noticed this as they're not load balancing their LUN distribution between nodes. For example: A two node cluster - node A and node B. 3 iSCSI targets are present on the cluster - 1,2 and 3. Node A currently has iSCSI targets 1 and 2. Node B currently has iSCSI target 3. -> Something happens and LUN 1 fails over to Node B. If the lio_iblock (iblock number) and scsi_sn (vpd_unit_serial) are not specified the generated SCSI ID may be different. I believe this happens because the ordering of the targets may be different after a failover and because the iSCSI PR is not replicated between the nodes. I don't think that the iSCSI PR *needs* to be replicated between the hosts if it is explicitly set and we have not been able to re-create the situation with the incorrect SCSI ID since ensuring the value of lio_iblock (iblock number) and the scsi_sn (vpd_unit_serial). I think the most confusing part of all of this is the difference in naming / terminology. - The resource agent talks about 'scsi_sn' - ConfigFS talks about 'vpd_unit_serial' - Xen / iSCSI initiators talk about 'SCSI ID' ��.n��������+%������w��{.n����j� ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
