Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1253790

Summary:	Consume fix for "iscsi_session recovery_tmo revert back to default when a path becomes active"
Product:	[oVirt] vdsm	Reporter:	Nir Soffer <nsoffer>
Component:	General	Assignee:	Nir Soffer <nsoffer>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Raz Tamir <ratamir>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.17.0	CC:	acanan, amureini, bazulay, bugs, ecohen, eedri, gklein, lsurette, mgoldboi, rbalakri, sbonazzo, ycui, yeylon, ylavi
Target Milestone:	ovirt-3.6.0-rc3	Flags:	rule-engine: ovirt-3.6.0+ rule-engine: blocker+ ylavi: planning_ack+ amureini: devel_ack+ amureini: testing_ack+
Target Release:	4.17.9
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	storage
Fixed In Version:	vdsm-4.17.9	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1272083 (view as bug list)		Environment:
Last Closed:	2015-11-27 07:56:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1253789
Bug Blocks:	1272083

Description Nir Soffer 2015-08-14 17:36:09 UTC

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.

Comment 1 Eyal Edri 2015-10-14 15:38:14 UTC

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

Comment 2 Allon Mureinik 2015-10-15 07:45:06 UTC

(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?

Comment 3 Raz Tamir 2015-11-22 08:46:42 UTC

Verified on vdsm-4.17.10.1-0.el7ev.noarch with kernel 3.10.0-327.el7.x86_64

Comment 4 Sandro Bonazzola 2015-11-27 07:56:06 UTC

Since oVirt 3.6.0 has been released, moving from verified to closed current release.