Bug 1032276

Summary:	[RFE] Ability to prioritize and limit I/O of image copy operations
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Jake Hunsaker <jhunsaker>
Component:	RFEs	Assignee:	Rob Young <royoung>
Status:	CLOSED WONTFIX	QA Contact:	Shai Revivo <srevivo>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	areis, dfediuck, fsimonce, knoel, kwolf, lpeer, mgoldboi, rbalakri, scohen, srevivo, stefanha, vgoyal
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	sherold: Triaged+
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-24 13:50:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	SLA	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	906938, 1124026
Bug Blocks:

Description Jake Hunsaker 2013-11-19 21:34:44 UTC

2. Who is the customer behind the request?  
Account: name (acct #)   Ärztekammer Schleswig-Holstein / 1494095
TAM customer: no/yes  no
SRM customer: no/yes  no
Strategic: no/yes  no
  
3. What is the nature and description of the request?  

Ability to control the I/O scheduling priority of creating a VM from a template.
  
4. Why does the customer need this? (List the business requirements here) 

Cust reports creating a VM from a template takes up a large amount of I/O resources on hypervisor which is causing a big performance degradation in running VMs.
  
5. How would the customer like to achieve this? (List the functional requirements here)  
  
Be able to classify the task as a lower priority than currently running VM threads. Akin to renice'ing a process.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.  

Test creating a VM template and see if VM performance is still being affected.
  
7. Is there already an existing RFE upstream or in Red Hat Bugzilla? 

No 
  
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?  

No
  
9. Is the sales team involved in this request and do they have any additional input?  

No
  
10. List any affected packages or components.

RHEV-H  
  
11. Would the customer be able to assist in testing this functionality if implemented? 

Yes

Comment 1 Ayal Baron 2013-11-21 06:47:14 UTC

I'm guessing the client is cloning the VM from the template, as creation of a thin image from the template should not create a lot of I/O.

Clone operations (full copy of the data) should definitely be capped and have reduced priority.
This cannot be done with ionice as it just doesn't really work (we already do that).
I can think of 2 ways of doing this:
1. limit through qemu. This would require one to run a VM from the template (read only or temp snap mode) and clone.
2. limit through cgroups. I don't recall if they've fixed it so that you can limit on deadline as well and not just cfq.

One additional thing that needs to be done is to try and offload the copy to the storage directly when relevant.

Comment 2 Itamar Heim 2013-11-21 08:01:18 UTC

if we go with cgroups, hopefully this can be as 'lower priority' rather than capping.

Comment 3 Ayal Baron 2013-11-21 13:04:14 UTC

Hi Vivek,

Do we have a way today to prioritize I/O when using deadline?

Comment 4 Vivek Goyal 2013-11-21 20:13:21 UTC

(In reply to Ayal Baron from comment #3)
> Hi Vivek,
> 
> Do we have a way today to prioritize I/O when using deadline?


Ayal, 

Deadline does not support IO priority only CFQ does. IO capping is supported though at block layer if that is useful in this context.

Comment 5 Jake Hunsaker 2013-12-30 15:12:51 UTC

Ayal, Vivek,

Just following up on this for the customer - is this definitely a 3.4.0 target? I take it this is not exactly a trivial feature?

Comment 6 Ayal Baron 2013-12-30 15:54:11 UTC

(In reply to Jake Hunsaker from comment #5)
> Ayal, Vivek,
> 
> Just following up on this for the customer - is this definitely a 3.4.0
> target? I take it this is not exactly a trivial feature?

this is not a 3.4 target as far as I know.
Doron?

Comment 7 Doron Fediuck 2013-12-31 08:25:48 UTC

(In reply to Ayal Baron from comment #6)
> (In reply to Jake Hunsaker from comment #5)
> > Ayal, Vivek,
> > 
> > Just following up on this for the customer - is this definitely a 3.4.0
> > target? I take it this is not exactly a trivial feature?
> 
> this is not a 3.4 target as far as I know.
> Doron?

You are correct.
I/O QoS is in our raodmap, but not in 3.4.

Comment 11 Federico Simoncelli 2015-03-02 22:59:01 UTC

Here's few notes that I collected over the time:

IIRC capping is doable (weighting is hard). It is possible to use cgroups to limit the io, and eventually use cgexec to run the command (or something fancier).

https://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt

ATM we cannot use cgroups on file-systems (yet) because of bug 1124026

It is possible to throttle in process (qemu-img) or in kernel. Here's a comparison:

Throttle in qemu-img:

- pros: works on all backends (easier to develop/modify/upgrade), no dependency on kernel
- cons: needs adjustments

Throttle in kernel:

- pros: no need for adjustments
- cons: requires implementation in kernel per backend[1] (probably slower development and harder to modify/upgrade)

[1] block device, file, network, etc.

Comment 13 Doron Fediuck 2018-06-24 13:50:36 UTC

Closing old issues.
If still relevant please provide the use case and re-open.

Comment 14 Franta Kust 2019-05-16 13:03:04 UTC

BZ<2>Jira Resync