Description of problem: see this mail: http://lists.ovirt.org/pipermail/devel/2014-October/009072.html Version-Release number of selected component (if applicable): all How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: patch at: http://gerrit.ovirt.org/#/c/33355/
I am not sure the posted patch really deals with the described scenario, so please clarify: The scenario is: I import a vm from an export domain into a local storage domain. Would this patch apply in this scenario? as far as I understood the commit message, the "qemu-img convert" uses the old image as a backing file and uses copy on write to write the new image. But afaik this would not work in the above scenario, because the export domain is just for importing and will be switched off afterwards? Please correct me if I did not understand your approach correctly, thanks!
How should this be tested?
(In reply to Yaniv Dary from comment #2) > How should this be tested? Import a VM to a block domain and observe in the VDSM log that it uses qemu-img and not dd.
This should also work for file backed domains like local storage domains. If not the posted commit does not belong to this RFE. Thanks
(In reply to Sven Kieske from comment #4) > This should also work for file backed domains like local storage domains. well, the gerrit comment message says it does and provides some numbers...
*commit message
(In reply to Michal Skrivanek from comment #5) > (In reply to Sven Kieske from comment #4) > > This should also work for file backed domains like local storage domains. > > well, the gerrit comment message says it does and provides some numbers... Thanks for the clarification, I stumbled over this statement: > - copying images from block domains we won't copy the entire chunk (1Gb) > but only the amount of data really in use because file domains were not mentioned there, but if you scroll down I see the tests where also done on file storage. Thanks for the clarification!
Verified, 'dd' command is not being used during importation of sparse virtual disks from exportdomain.
oVirt 3.6.0 has been released on November 4th, 2015 and should fix this issue. If problems still persist, please open a new BZ and reference this one.