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:
Correction: Wrong bug referenced above. It should be BZ 1029288, not 662058.
Lowering priority based on comment 7.
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.
(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?
(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?
(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.
This should wait till we have a copyImage verb(s) that are SPM-independent.
Yaniv, how is this related to spm?
(In reply to Nir Soffer from comment #14) > Yaniv, how is this related to spm? See comment #13
(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".