Bug 1257240 - Template's disk format is wrong
Template's disk format is wrong
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
Unspecified Unspecified
unspecified Severity high (vote)
: ovirt-3.6.1
: 3.6.1
Assigned To: Idan Shaby
Raz Tamir
: Automation, Regression
Depends On:
  Show dependency treegraph
Reported: 2015-08-26 10:51 EDT by Raz Tamir
Modified: 2016-02-10 11:57 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-12-16 07:18:57 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑3.6.z+
rule-engine: blocker+
ylavi: planning_ack+
tnisan: devel_ack+
rule-engine: testing_ack+

Attachments (Terms of Use)
vdsm and engine logs (195.26 KB, application/x-gzip)
2015-08-26 10:51 EDT, Raz Tamir
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 47475 master MERGED backend: fix template's disk volume info Never
oVirt gerrit 47476 master MERGED frontend: default volume format selection in new template window Never
oVirt gerrit 47579 ovirt-engine-3.6 MERGED backend: fix template's disk volume info Never
oVirt gerrit 48084 master MERGED backend: add missing MockitoJUnitRunner annotation Never
oVirt gerrit 48105 ovirt-engine-3.6 MERGED frontend: default volume format selection in new template window Never

  None (edit)
Description Raz Tamir 2015-08-26 10:51:51 EDT
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:
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:{
     “DiskAlias":"vm_prealloc_disk_image_Disk1","DiskDescription":"Active VM"

Version-Release number of selected component (if applicable):

How reproducible:

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:
Comment 1 Tal Nisan 2015-08-27 05:25:59 EDT
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?
Comment 3 Arik 2015-08-31 03:14:25 EDT
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.
Comment 4 Raz Tamir 2015-08-31 03:58:53 EDT
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.
Comment 5 Arik 2015-08-31 04:34:08 EDT
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).
Comment 6 Tal Nisan 2015-08-31 06:14:16 EDT
Given the latest conclusions I'm putting you back as assignee
Comment 7 Tal Nisan 2015-08-31 06:59:31 EDT
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
Comment 8 Allon Mureinik 2015-10-12 07:56:45 EDT
Discussed with Yaniv D - this isn't critical for oVirt 3.6.0 GA - pushing out to oVirt 3.6.1.
Comment 9 Red Hat Bugzilla Rules Engine 2015-10-12 07:56:47 EDT
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.
Comment 10 Red Hat Bugzilla Rules Engine 2015-10-19 07:01:58 EDT
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.
Comment 11 Yaniv Lavi 2015-10-29 08:31:20 EDT
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.
Comment 12 Elad 2015-12-07 10:30:34 EST
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)

Template disk created as preallocated

4) Created a VM from the template (as cloned) 

VM disk created as preallocated

Comment 13 Elad 2015-12-07 10:32:42 EST
Tested with the default parameters. 
Template creation:

<vm id="659c2ea8-88df-4c25-8f64-331ac383c453"/>
Comment 14 Sandro Bonazzola 2015-12-16 07:18:57 EST
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.

Note You need to log in before you can comment on or make changes to this bug.