Bug 1464931
Summary: | [downstream clone - 4.1.3] Creating a Clone vm from template with Format "QCOW2" and Target "block based storage" has a disk with same actual and virtual size. | ||
---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | rhev-integ |
Component: | vdsm | Assignee: | Dan Kenigsberg <danken> |
Status: | CLOSED ERRATA | QA Contact: | Kevin Alon Goldblatt <kgoldbla> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.0.6 | CC: | achareka, amureini, bazulay, bgraveno, ebenahar, eedri, eshenitz, kgoldbla, lsurette, mkalinin, mlipchuk, ratamir, rbalakri, Rhev-m-bugs, srevivo, tnisan, ycui, ykaul, ylavi |
Target Milestone: | ovirt-4.1.3 | Keywords: | ZStream |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1419240 | Environment: | |
Last Closed: | 2017-07-06 07:32:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1419240 | ||
Bug Blocks: |
Description
rhev-integ
2017-06-26 09:15:14 UTC
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. (Originally by Maor Lipchuk) 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? (Originally by Maor Lipchuk) Moving out all non blocker\exceptions. (Originally by Yaniv Dary) Bug 1433670 won't be available in 4.1.z's timeframe. Moving out to 4.2. (Originally by Allon Mureinik) Maor, how can this bug be on POST? Where's the link to the patch? (Originally by Allon Mureinik) (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. (Originally by Maor Lipchuk) Retargeting to 4.1.z based on the patches. (Originally by Allon Mureinik) 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! (Originally by Kevin Goldblatt) 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 (Originally by Eyal Shenitzky) Created attachment 1285671 [details]
engine and vdsm logs
(Originally by Eyal Shenitzky)
(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 (Originally by Maor Lipchuk) 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 (Originally by Eyal Shenitzky) 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 (Originally by Eyal Shenitzky) 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 (Originally by Maor Lipchuk) 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 (Originally by Eyal Shenitzky) Verified with the following code: -------------------------------------- ovirt-engine-4.1.3.4-0.1.el7.noarch rhevm-4.1.3.4-0.1.el7.noarch vdsm-4.19.19-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 Virtual size was 10G and the Actual size on the block storage of the Qcow2 disk is 1G Moving to VERIFIED 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-2017:1696 This is a cloned bug of bug 1419240 which has qe_test_coverage+ |