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

Bug 1132200

Summary:	[BLOCKED] 'qemu-img convert -t none' is very slow when VDSM exports qcow2 images
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Gordon Watson <gwatson>
Component:	vdsm	Assignee:	Adam Litke <alitke>
Status:	CLOSED WONTFIX	QA Contact:	Aharon Canan <acanan>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.1.0	CC:	amureini, bazulay, ecohen, iheim, lpeer, mkalinin, nsoffer, rpai, tnisan, yeylon, ylavi
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:	storage
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-22 08:28:10 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:	1185830
Bug Blocks:

Description Gordon Watson 2014-08-20 21:35:00 UTC

Description of problem:

This is a follow-on from BZ 662058. That bug described an issue that wasn't specific to export domains.

So, the intent of this bug is to suggest that exporting qcow2 images to an export domain using 'qemu-img convert -t none' is too slow and that maybe a caching option might be preferable.


Version-Release number of selected component (if applicable):

- RHEV 3.1
- RHEL 6.5 hosts with 'vdsm-4.14.7-3'.


How reproducible:


Steps to Reproduce:

1. Either export a VM/disk that contains a qcow2 image via the Admin Portal or manually execute the command(s) that VDSM runs, e.g. 'qemu-img convert -t none -f qcow2 cow_image_path -O export_image_path' and check how long it takes.

2. Manually execute 'qemu-img convert -f qcow2 cow_image_path -O export_image_path' and check how long it takes.



Actual results:

The customer's tests showed that using '-t none' increased the execution time by a factor of about 3 over either using a caching option or using the 'dd' command.

Expected results:

They would like to be able to reliably export VMs in the shortest time possible.


Additional info:

Comment 1 Gordon Watson 2014-08-20 21:47:42 UTC

Correction:  Wrong bug referenced above. It should be BZ 1029288, not 662058.

Comment 8 Nir Soffer 2014-12-11 16:04:02 UTC

Lowering priority based on comment 7.

Comment 9 Nir Soffer 2015-02-03 13:00:19 UTC

According to Federico comment https://bugzilla.redhat.com/show_bug.cgi?id=1029288#c15, we can enable caching when copying images to export domain, but we will need extensive stress testing to ensure that caching does not effect io to other domains.

We can also make this a configurable option, so customers can enable this feature if it works for them.

Returning priority to unspecified as we did not prioritize this yet.

Comment 10 Allon Mureinik 2015-02-04 11:48:03 UTC

(In reply to Nir Soffer from comment #9)
> According to Federico comment
> https://bugzilla.redhat.com/show_bug.cgi?id=1029288#c15, we can enable
> caching when copying images to export domain, but we will need extensive
> stress testing to ensure that caching does not effect io to other domains.
> 
> We can also make this a configurable option, so customers can enable this
> feature if it works for them.
> 
> Returning priority to unspecified as we did not prioritize this yet.
Gil, we need the scale's team commitment here in order to move forward.
Is this feasible for 3.6.0's timeframe?

Comment 11 Gil Klein 2015-03-09 12:38:23 UTC

(In reply to Allon Mureinik from comment #10)
> (In reply to Nir Soffer from comment #9)
> > According to Federico comment
> > https://bugzilla.redhat.com/show_bug.cgi?id=1029288#c15, we can enable
> > caching when copying images to export domain, but we will need extensive
> > stress testing to ensure that caching does not effect io to other domains.
> > 
> > We can also make this a configurable option, so customers can enable this
> > feature if it works for them.
> > 
> > Returning priority to unspecified as we did not prioritize this yet.
> Gil, we need the scale's team commitment here in order to move forward.
> Is this feasible for 3.6.0's timeframe?
Seems to be feasible if we will get it early enough for testing.
Do you think it can be ready for the beta milestone?

Comment 12 Allon Mureinik 2015-03-11 10:10:17 UTC

(In reply to Gil Klein from comment #11)
> (In reply to Allon Mureinik from comment #10)
> > (In reply to Nir Soffer from comment #9)
> > > According to Federico comment
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1029288#c15, we can enable
> > > caching when copying images to export domain, but we will need extensive
> > > stress testing to ensure that caching does not effect io to other domains.
> > > 
> > > We can also make this a configurable option, so customers can enable this
> > > feature if it works for them.
> > > 
> > > Returning priority to unspecified as we did not prioritize this yet.
> > Gil, we need the scale's team commitment here in order to move forward.
> > Is this feasible for 3.6.0's timeframe?
> Seems to be feasible if we will get it early enough for testing.
> Do you think it can be ready for the beta milestone?
sounds feasible.

Comment 13 Allon Mureinik 2015-03-22 15:15:55 UTC

This should wait till we have a copyImage verb(s) that are SPM-independent.

Comment 14 Nir Soffer 2015-07-23 12:29:12 UTC

Yaniv, how is this related to spm?

Comment 15 Yaniv Lavi 2015-08-09 16:50:28 UTC

(In reply to Nir Soffer from comment #14)
> Yaniv, how is this related to spm?

See comment #13

Comment 16 Nir Soffer 2015-08-11 19:02:48 UTC

(In reply to Yaniv Dary from comment #15)
> (In reply to Nir Soffer from comment #14)
> > Yaniv, how is this related to spm?
> 
> See comment #13

qemu-img convert -t none will not change its behavior when we work in
spm-less mode. Changing category to "scale".