Description of problem: Trying to create new Pool based on a Template with at least one existed disk and checking the 'Auto select target' check box (in 'Resource Allocation' side tab), causes the whole pool creation to fail. (this check box is used for dynamically allocating the disks among SDs - please see bug 1081536 for feature details). According to feature bug 1081536, this was tested on 4.1.1 and therefore it is a regression. Version-Release number of selected component (if applicable): 4.2 master How reproducible: 100% Steps to Reproduce: 1.Open a new Pool dialog 2.Select a Template with at least one existed disk. 3. Go to 'Resource Allocation' side tab and check the 'Auto select target' check box. Actual results: The Pool creation fails in async call to addVMCommand because it tries to create Pool's VMs with images of RAW volume type instead of COW. The following WARN appears in engine.log: "Validation of action 'AddVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_FAILED_THIN_TEMPLATE_DISKS_SHOULD_ONLY_BE_COW ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-13) [5d1908ac-4b19-4322-8632-91494c42 3037] EVENT_ID: USER_ADD_VM_POOL_WITH_VMS_FAILED(303), Failed to create VM Pool" Expected results: Pool creation should succeed. Additional info: The Bug is because in case the 'Auto select target' is checked, we copy the Pool's template images as is in CommonVmPoolCommand (and in case they are in RAW format, they stay in that format). The fix should override the format to COW in Backend - the same as done in Frontend if 'Auto select target' check box is not set.
I have a patch ready for master branch for fixing this bug
patch seems to be trivial - targeting 4.1.6 @Meital: any chance to enrich the automation of pool testing to make sure also this flow is tested?
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.
Tomas, can we set Target Milestone to 4.1.5 (since a patch for master was merged already)?
Verification builds: ovirt-engine-4.1.5.2-0.1.el7 libvirt-client-3.2.0-14.el7_4.2.x86_64 vdsm-4.19.28-1.el7ev.x86_64 qemu-kvm-rhev-2.9.0-16.el7_4.3.x86_64 sanlock-3.5.0-1.el7.x86_64