Created attachment 1067283 [details] vdsm and engine logs Description of problem: When creating vm with preallocated disk (RAW) and creating snapshot from that vm, the disk's allocation policy changed to thin provision. In case we create a template from that vm, the template disk should be preallocated. In 3.5: CopyImageVDSCommand( storagePoolId = 47020503-8bf2-4f62-a826-6e86d544072c, ignoreFailoverLimit = false, storageDomainId = a491a2f7-24a5-41eb-9253-808e9faa41d5, imageGroupId = 08f7423b-a9c8-43a5-9dc7-314c481e1398, imageId = 4fc8f5b8-f770-4898-9ce4-5ef6b359a510, dstImageGroupId = d0ad7ae1-cf33-43f3-8f4f-db0d853b1cd2, vmId = fad5f07c-3fe5-4d52-ba6d-0da4186860d5, dstImageId = 93d636cf-1232-4742-8838-61553ceb479f, imageDescription = Active VM, dstStorageDomainId = a491a2f7-24a5-41eb-9253-808e9faa41d5, copyVolumeType = SharedVol, volumeFormat = RAW, preallocate = Preallocated, postZero = false, force = false ) In 3.6: CopyImageVDSCommand( CopyImageVDSCommandParameters:{ runAsync='true', storagePoolId='9f5fb006-6d26-4651-9d8e-83881690b7c4', ignoreFailoverLimit='false', storageDomainId='4eb0327d-5fa7-4467-833b-f7e058cdf690', imageGroupId='bc8a7be8-2918-453f-8cb6-19f5236f688e', imageId='ebec69f9-8839-4cf3-8bbc-e5df75c048ea', dstImageGroupId='bd503d5b-f8e8-4fe5-9782-f18fd5a75c8b', vmId='ce6aae75-8f1f-45a0-be5d-92e6e567c0c4', dstImageId='d89ff18a-a8b6-4800-8770-f6af440deb69', imageDescription='{ “DiskAlias":"vm_prealloc_disk_image_Disk1","DiskDescription":"Active VM" }', dstStorageDomainId='4eb0327d-5fa7-4467-833b-f7e058cdf690', copyVolumeType='SharedVol', volumeFormat='COW', preallocate='Sparse', postZero='false', force='false' }) Version-Release number of selected component (if applicable): rhevm-3.6.0-0.12.master.el6.noarch vdsm-4.17.3-1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Create a vm with preallocated disk 2. Create snapshot from that vm 3. Make template from that vm Actual results: Expected results: Additional info:
Arik, this seems related to the format change you introduced which allows you to select the template format, thing is that the default should remain as it was in 3.5, can you please have a look?
On the engine side the implementation preserves backward-compatibility, therefore I assume that the operation was done in the webadmin. I think the severity of this bug is low since it is just about the default selection in the UI. The volume format was set to QCOW and thus the preallocation type was set to sparse. If the user selects RAW format on block device, then the preallocation type will remain PREALLOCATED. I'm not sure that it is a regression since the make-template dialog have changed significantly - now the user doesn't select the preallocation type anymore but its format instead, so he needs to select the right format. This BZ can be considered as a request to set the default volume format in the make-template dialog according to the preallocation type of the original volume of the disk instead.
Hi Arik, your first assumption was not true. The operation was done using REST api, without selecting the volume format. I'm raising the severity because this bug cause many of our automated cases to skip.
Ah ok, in that case it is a different story. Indeed, I missed the fact that REST-API passes the latest volume of the disk and in that case we think of it as if it requests the template disk to have the same preallocation type of this volume. We need to differentiate the case where the given image holds the format that was asked by the user from the case where it is an image that was passed from the REST-API (maybe REST-API can override the format with the format of the base volume when calling AddVmTemplate).
Given the latest conclusions I'm putting you back as assignee
Idan, please have a look when you can, consult Arik to find the fix location more easily as he is most familiar with this feature
Discussed with Yaniv D - this isn't critical for oVirt 3.6.0 GA - pushing out to oVirt 3.6.1.
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Steps: 1) Created a VM with preallocated disk attached 2) Created a snapshot to the VM, the disk allocation policy changed to thin 3) Created a template out of the VM (from Webadmin and from REST) Results: Template disk created as preallocated 4) Created a VM from the template (as cloned) Results: VM disk created as preallocated Used: rhevm-3.6.1.1-0.1.el6.noarch rhevm-restapi-3.6.1.1-0.1.el6.noarch vdsm-4.17.12-0.el7ev.noarch
Tested with the default parameters. Template creation: <template> <vm id="659c2ea8-88df-4c25-8f64-331ac383c453"/> <name>temp11</name> </template>
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.