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:
We'll probably fix by fallocate() and not the regular 'dd' ?
(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?
(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
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.
*** Bug 1403183 has been marked as a duplicate of this bug. ***
(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
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
Veridy according to https://bugzilla.redhat.com/show_bug.cgi?id=1585030#c11
INFO: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Project 'vdsm'/Component 'ovirt-engine' mismatch] For more info please contact: rhv-devops
Verified Cloned VM has the same disk allocation as original VM. vdsm-4.30.6-1.el7ev.x86_64 ovirt-engine-4.3.0-0.8.rc2.el7.noarch The disk of original VM : [root@storage-ge9-vdsm3 53b83ce3-7a6c-4578-8620-46e664712d72]# qemu-img info /rhev/data-center/9807da5c-e4f9-4e5b-b9d1-b88fc9003d62/ce04fdbe-21b9-4f48-9bf3-51822d75096a/images/53b83ce3-7a6c-4578-8620-46e664712d72/57b33c52-2a01-49ad-9c09-a8931efea446 image: /rhev/data-center/9807da5c-e4f9-4e5b-b9d1-b88fc9003d62/ce04fdbe-21b9-4f48-9bf3-51822d75096a/images/53b83ce3-7a6c-4578-8620-46e664712d72/57b33c52-2a01-49ad-9c09-a8931efea446 file format: raw virtual size: 5.0G (5368709120 bytes) disk size: 0 The disk of clone vm [root@storage-ge9-vdsm3 410ed63e-471d-4465-93da-29541d975644]# qemu-img info /rhev/data-center/9807da5c-e4f9-4e5b-b9d1-b88fc9003d62/ce04fdbe-21b9-4f48-9bf3-51822d75096a/images/410ed63e-471d-4465-93da-29541d975644/55a04dd8-a1a3-426b-99ee-0482d8597aac image: /rhev/data-center/9807da5c-e4f9-4e5b-b9d1-b88fc9003d62/ce04fdbe-21b9-4f48-9bf3-51822d75096a/images/410ed63e-471d-4465-93da-29541d975644/55a04dd8-a1a3-426b-99ee-0482d8597aac file format: raw virtual size: 5.0G (5368709120 bytes) disk size: 0
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-2019:1085