Description of problem: iSCSI default replacement_timeout is 120 seconds, resulting in too slow iSCSI failover in multipath setup. In vdsm, this may lead to blocking of multiple unrelated vdsm threads for many minutes, when lvm, multipath ore scsi scan operation blocks. This issue was resolved in multipath (bug 1099932), by configuring iscsi session recovery_tmo sysfs attribute to multipath fast_io_fail_tmo value, (5 seconds in vdsm configuration). However, this configuration was reverted to the default 120 seconds after a device went down an up again, or after restart of the iscsid daemon (bug 1139038). This issue was fixed in kernel-3.10.0-295.el7. In this version, setting session recovery_tmo using sysfs overrides the default value defined in iscsid configuration file. Vdsm need to require a kernel containing a fix for this issue on Fedora versions including this fix.
shouldn't this bug has 3.5.z? flag set if the target milestone is set to 3.5.6? trying to understand how clone candidates are treated in the new classification
(In reply to Eyal Edri from comment #1) > shouldn't this bug has 3.5.z? flag set if the target milestone is set to > 3.5.6? > trying to understand how clone candidates are treated in the new > classification Yeah, probably so. This is waiting for qa-ack+ so we can clone it. Gil - can you assist?
Verified on vdsm-4.17.10.1-0.el7ev.noarch with kernel 3.10.0-327.el7.x86_64
Since oVirt 3.6.0 has been released, moving from verified to closed current release.