Description of problem: Creating a Clone vm from template with Format "QCOW2" and Target "block based storage" created disks with actual and virtual size same. Version-Release number of selected component (if applicable): Red Hat Virtualization Manager Version: 4.0.6.3-0.1.el7ev How reproducible: Always. Steps to Reproduce: 1. Create a New VM from template. 2. Select Format "QCOW2". 3. Select any block based storage. Actual results: Actual size and Virtual size is same. Expected results: Virtual size should not be same as actual size. Additional info: File based storage do not have this issue.
This seems like a duplicate of https://bugzilla.redhat.com/1358717 - Export of vm with thin provision disk from NFS Data domain and Import to Block Data domain makes virtual and Actual size of disk same. when importing a volume using qemu-img convert to block storage, we create full size volume since we cannot predict the size of the qemu file after the copy. We plan to discuss this issue with qemu to provide us an API so we can predicate the allocation size that is needed when using qemu-img convert.
Ameya, Just to make sure it is indeed a duplicate of BZ1358717, was the original storage domain that the Template's disk was reside on is file system?
Moving out all non blocker\exceptions.
Bug 1433670 won't be available in 4.1.z's timeframe. Moving out to 4.2.
Maor, how can this bug be on POST? Where's the link to the patch?
(In reply to Allon Mureinik from comment #7) > Maor, how can this bug be on POST? > Where's the link to the patch? Sorry, I got disrupted with something else. Part of the verification tests were also testing the scenario described here, so those patches should also solve it.
Retargeting to 4.1.z based on the patches.
Verified with the following code: ---------------------------------------- rhevm-4.1.2-0.1.el7.noarch ovirt-engine-4.1.2-0.1.el7.noarch vdsm-4.19.11-1.el7ev.x86_64 Verified with the following scenario: ---------------------------------------- Steps to Reproduce: 1. Create a New VM from template. 2. Select Format "QCOW2". 3. Select any block based storage. The Actual and Virtual sizes were correctly displayed When Virtual was 2g and actual 1g in the originally the same was displayed for the new vm from template Tested for iscsi thin and preallocated, nfs thin and preallocated Only the iscsi preallocated correctly displayed an actual size of 2g as was the orinal volumes size Moving to VERIFIED!
Reopen the bug, reproduced on the following version: Engine: 4.2.0-0.0.master.20170602194647.gitaf23eb5.el7.centos VDSM: 4.20.0-970.gitf0c24e5.el7.centos.x86_64 Steps to Reproduce: 1. Create a New VM from template. 2. Select Format "QCOW2". 3. Select any block based storage Add vdsm and engine logs
Created attachment 1285671 [details] engine and vdsm logs
(In reply to Eyal Shenitzky from comment #11) > Reopen the bug, reproduced on the following version: > > Engine: 4.2.0-0.0.master.20170602194647.gitaf23eb5.el7.centos > VDSM: 4.20.0-970.gitf0c24e5.el7.centos.x86_64 > > > Steps to Reproduce: > 1. Create a New VM from template. > 2. Select Format "QCOW2". > 3. Select any block based storage > > Add vdsm and engine logs Which operation was it exactly? From the logs it seems that your last copy actions were done on an NFS destination storage domain: 2017-06-07 09:06:07,574+03 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand] .... sdUUID=036a9549-1b06-4477-a5db-23e7d478520d dstSdUUID=ccafa05c-9d71-43c4-96fc-ad7f225f6207 Also 2017-06-07 08:52:45,971+03 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CopyImageVDSCommand] (default task-2) [disks_syncAction_e0ec016f-effb-416a] START, CopyImageVDSCommand ... dstSdUUID=64b63ab9-4c74-4171-9d5d-a1430aa06dc0 sdUUID=036a9549-1b06-4477-a5db-23e7d478520d: sd_type_0709053071 = yellow-vdsb.qa.lab.tlv.redhat.com:/Storage_NFS/storage_local_ge10_nfs_3
There were few copies in order to verify it occurs only on block based as mention in the bug, there was a copy earlier with the scenario above. Close this bug and reopen on 4.2
Actually, now that I look in the logs again, I can't seem to find any reference of copy to block storage domain. The only iSCSI SDs are: iscsi_1=5737d729-23b9-4fb8-ad26-b443b970c908 iscsi_2=63212961-9d6c-4977-a11c-d73b9ae43e67 iscsi_0=50c4a7b4-2567-4710-9c92-34a58daf5d3e and there is no copy operation with one of those IDs as destination. Can you please provide the iSCSI sd name of the destination storage which you copied to
The relevant operation is create VM from a template as clone with disk QCOW. not copy disk. But let's move the conversation to the relevant bug - https://bugzilla.redhat.com/show_bug.cgi?id=1459455
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [No relevant external trackers attached] For more info please contact: rhv-devops
INFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [No relevant external trackers attached] For more info please contact: rhv-devops
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:1488
BZ<2>Jira Resync