Bug 1419240 - Creating a Clone vm from template with Format "QCOW2" and Target "block based storage" has a disk with same actual and virtual size.
Summary: Creating a Clone vm from template with Format "QCOW2" and Target "block based...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.2.0
: ---
Assignee: Maor
QA Contact: Kevin Alon Goldblatt
URL:
Whiteboard:
Depends On: 1433670
Blocks: 1464931
TreeView+ depends on / blocked
 
Reported: 2017-02-04 06:13 UTC by Ameya Charekar
Modified: 2019-05-16 13:08 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1464931 (view as bug list)
Environment:
Last Closed: 2018-05-15 17:40:52 UTC
oVirt Team: Storage
Target Upstream Version:


Attachments (Terms of Use)
engine and vdsm logs (2.00 MB, application/x-gzip)
2017-06-07 06:57 UTC, Eyal Shenitzky
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:1488 None None None 2018-05-15 17:42:08 UTC
oVirt gerrit 75591 ovirt-4.1 MERGED qcow2: Calculate estimated size for converted qcow volumes. 2017-04-19 11:41:00 UTC
oVirt gerrit 75592 ovirt-4.1 MERGED image: Allocate initial size for converted RAW volume. 2017-04-19 11:41:36 UTC
oVirt gerrit 75697 ovirt-4.1 MERGED image: typo leading to AttributeError 2017-04-20 15:00:40 UTC
Red Hat Bugzilla 1358717 None CLOSED Export of vm with thin provision disk from NFS Data domain and Import to Block Data domain makes virtual and Actual size... 2019-08-25 14:05:02 UTC

Internal Links: 1358717

Description Ameya Charekar 2017-02-04 06:13:42 UTC
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.

Comment 2 Maor 2017-02-05 13:19:49 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.

Comment 3 Maor 2017-02-07 15:07:35 UTC
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?

Comment 5 Yaniv Lavi 2017-02-23 11:25:40 UTC
Moving out all non blocker\exceptions.

Comment 6 Allon Mureinik 2017-03-19 16:23:03 UTC
Bug 1433670 won't be available in 4.1.z's timeframe. Moving out to 4.2.

Comment 7 Allon Mureinik 2017-04-18 16:22:22 UTC
Maor, how can this bug be on POST?
Where's the link to the patch?

Comment 8 Maor 2017-04-18 16:41:10 UTC
(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.

Comment 9 Allon Mureinik 2017-04-18 16:45:43 UTC
Retargeting to 4.1.z based on the patches.

Comment 10 Kevin Alon Goldblatt 2017-04-27 16:03:44 UTC
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!

Comment 11 Eyal Shenitzky 2017-06-07 06:56:39 UTC
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

Comment 12 Eyal Shenitzky 2017-06-07 06:57:33 UTC
Created attachment 1285671 [details]
engine and vdsm logs

Comment 14 Maor 2017-06-07 07:31:12 UTC
(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

Comment 15 Eyal Shenitzky 2017-06-07 08:08:44 UTC
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

Comment 16 Eyal Shenitzky 2017-06-07 08:08:58 UTC
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

Comment 17 Maor 2017-06-07 08:32:54 UTC
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

Comment 18 Eyal Shenitzky 2017-06-11 06:16:34 UTC
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

Comment 23 RHV Bugzilla Automation and Verification Bot 2017-12-06 16:18:11 UTC
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@redhat.com

Comment 24 RHV Bugzilla Automation and Verification Bot 2017-12-12 21:15:17 UTC
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@redhat.com

Comment 25 RHV Bugzilla Automation and Verification Bot 2017-12-18 17:05:41 UTC
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@redhat.com

Comment 28 errata-xmlrpc 2018-05-15 17:40:52 UTC
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

Comment 29 Franta Kust 2019-05-16 13:08:48 UTC
BZ<2>Jira Resync


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