+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1429286 +++ ====================================================================== Description of problem: When we clone a VM with RAW-Preallocated disk, the newly created VM is having having RAW-Sparse instead of RAW-Preallocated . We are doing qemu-img convert for copying the disk while cloning the VM. The "qemu-img convert" can automatically sparsifies any disk sector which contains all zeroes. So the new image will be equal to space actually used within the VM. So the behavior seems to be expected. But the user expect the disk space to be fully allocated on the storage when it show Preallocated disk type. Version-Release number of selected component (if applicable): ovirt-engine-4.0.6.3-0.1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Create a VM with preallocated disk on file based storage domain. 2. Clone this VM. 3. Check the disk size of newly created image using qemu-img info . Actual results: Preallocated disk is converted to RAW-sparse while cloning a VM in file based storage domain Expected results: Cloned VM should have the same disk allocation as original VM. Additional info: (Originally by Nijin Ashok)
We'll probably fix by fallocate() and not the regular 'dd' ? (Originally by Yaniv Kaul)
(In reply to Yaniv Kaul from comment #2) > We'll probably fix by fallocate() and not the regular 'dd' ? Agreed, do we have a RFE to block this bug on? (Originally by ylavi)
(In reply to Yaniv Dary from comment #3) > (In reply to Yaniv Kaul from comment #2) > > We'll probably fix by fallocate() and not the regular 'dd' ? > > Agreed, do we have a RFE to block this bug on? https://bugzilla.redhat.com/1391859 (Originally by Yaniv Kaul)
This is partly a duplicate of 1532133. We have several flows when cloning images: - Collapsing the original chain to single volume - uses Volume.copy. It needs a similar fix to the one applied for bug 1532133. - Copying all volumes to target image, cluster version 4.1 - uses SDM.copy_data these patches handle the vdsm side: https://gerrit.ovirt.org/#/q/topic:copy-data-prealloc More work is needed for engine side. - Copying all volumes to target image, cluster version < 4.1 - uses Image.move, it is already fixed by the fix to bug 1532133. (Originally by Nir Soffer)
*** Bug 1403183 has been marked as a duplicate of this bug. *** (Originally by Eyal Shenitzky)
(In reply to Nir Soffer from comment #5) > This is partly a duplicate of 1532133. > > We have several flows when cloning images: > > - Collapsing the original chain to single volume - uses Volume.copy. It > needs a > similar fix to the one applied for bug 1532133. > > - Copying all volumes to target image, cluster version 4.1 - uses > SDM.copy_data > these patches handle the vdsm side: > https://gerrit.ovirt.org/#/q/topic:copy-data-prealloc > More work is needed for engine side. > > - Copying all volumes to target image, cluster version < 4.1 - uses > Image.move, > it is already fixed by the fix to bug 1532133. This bug fix refers to the following flows: - Clone VM - Copy (floating/VM/template) disk - Clone VM from a snapshot - Import VM from an export domain - Create VM template - Create VM template from a snapshot I've open new bug 1571285 to track the solution for cold storage migration that uses SDM.copy_data on vdsm - https://gerrit.ovirt.org/#/q/topic:copy-data-prealloc (Originally by Eyal Shenitzky)
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.2.z': '?'}', ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.2.z': '?'}', ] For more info please contact: rhv-devops (Originally by rhv-bugzilla-bot)
When creating new image, the new image is exactly the same as the original VM.
4.2.4.2-0.1 version
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:2072
BZ<2>Jira Resync
sync2jira