Bug 1119660

Summary:	[RFE][RHEV] storage migration bandwidth limitation
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Evgheni Dereveanchin <ederevea>
Component:	RFEs	Assignee:	Rob Young <royoung>
Status:	CLOSED DEFERRED	QA Contact:	Shai Revivo <srevivo>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.4.0	CC:	johannes.tiefenbacher, lpeer, mgoldboi, pablo.iranzo, srevivo, ykaul
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	sherold: Triaged+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-01 14:47:01 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:	1043226
Bug Blocks:

Description Evgheni Dereveanchin 2014-07-15 09:01:08 UTC

Description of problem:
It is impossible to limit bandwidth used for storage migration tasks. This can cause storage network and SAN congestion issues preventing normal cluster operation

Version-Release number of selected component (if applicable):
vdsm-4.14.7-3.el6ev.x86_64

How reproducible:
always

Steps to Reproduce:
1. iSCSI SAN and all hosts connected over a 1 gbps link using dedicated storage network
2. start a storage migration

Actual results:
3. SPM saturates 1 gbps link on the SAN port
4. other hosts have problems reaching the SAN

Expected results:
3. bandwidth limit configured on SPM, it only uses that limit for storage migrations
4. other hosts in the cluster have no issues reaching the SAN

Additional info:
technology and link speed may vary. THe important point here is that storage migrations may saturate the SAN and negatively affect other hosts and VMs on them.

Comment 5 Michal Skrivanek 2020-03-19 15:40:41 UTC

We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it.
If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.

Comment 6 Michal Skrivanek 2020-04-01 14:47:01 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 7 Michal Skrivanek 2020-04-01 14:50:44 UTC

ok, closing. Please reopen if still relevant/you want to work on it.