Bug 1419240
Summary: | 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: | Ameya Charekar <achareka> | ||||
Component: | ovirt-engine | Assignee: | Maor <mlipchuk> | ||||
Status: | CLOSED ERRATA | QA Contact: | Kevin Alon Goldblatt <kgoldbla> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 4.0.6 | CC: | achareka, eedri, eshenitz, kgoldbla, lsurette, mkalinin, mlipchuk, ratamir, rbalakri, Rhev-m-bugs, srevivo, tnisan, ykaul, ylavi | ||||
Target Milestone: | ovirt-4.2.0 | Keywords: | ZStream | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | No Doc Update | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 1464931 (view as bug list) | Environment: | |||||
Last Closed: | 2018-05-15 17:40:52 UTC | Type: | Bug | ||||
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: | 1433670 | ||||||
Bug Blocks: | 1464931 | ||||||
Attachments: |
|
Description
Ameya Charekar
2017-02-04 06:13:42 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. 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 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 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 |