Bug 1464931 - [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.
[downstream clone - 4.1.3] Creating a Clone vm from template with Format "QCO...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
4.0.6
Unspecified Unspecified
unspecified Severity medium
: ovirt-4.1.3
: ---
Assigned To: Dan Kenigsberg
Kevin Alon Goldblatt
: ZStream
Depends On: 1419240
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-26 05:15 EDT by rhev-integ
Modified: 2017-07-06 03:32 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1419240
Environment:
Last Closed: 2017-07-06 03:32:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 75591 ovirt-4.1 MERGED qcow2: Calculate estimated size for converted qcow volumes. 2017-06-26 05:17 EDT
oVirt gerrit 75592 ovirt-4.1 MERGED image: Allocate initial size for converted RAW volume. 2017-06-26 05:17 EDT
oVirt gerrit 75697 ovirt-4.1 MERGED image: typo leading to AttributeError 2017-06-26 05:17 EDT

  None (edit)
Description rhev-integ 2017-06-26 05:15:14 EDT
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1419240 +++
======================================================================

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.

(Originally by Ameya Charekar)
Comment 3 rhev-integ 2017-06-26 05:15:29 EDT
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)
Comment 4 rhev-integ 2017-06-26 05:15:34 EDT
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)
Comment 6 rhev-integ 2017-06-26 05:15:45 EDT
Moving out all non blocker\exceptions.

(Originally by Yaniv Dary)
Comment 7 rhev-integ 2017-06-26 05:15:50 EDT
Bug 1433670 won't be available in 4.1.z's timeframe. Moving out to 4.2.

(Originally by Allon Mureinik)
Comment 8 rhev-integ 2017-06-26 05:15:57 EDT
Maor, how can this bug be on POST?
Where's the link to the patch?

(Originally by Allon Mureinik)
Comment 9 rhev-integ 2017-06-26 05:16:02 EDT
(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)
Comment 10 rhev-integ 2017-06-26 05:16:11 EDT
Retargeting to 4.1.z based on the patches.

(Originally by Allon Mureinik)
Comment 11 rhev-integ 2017-06-26 05:16:17 EDT
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)
Comment 12 rhev-integ 2017-06-26 05:16:22 EDT
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)
Comment 13 rhev-integ 2017-06-26 05:16:28 EDT
Created attachment 1285671 [details]
engine and vdsm logs

(Originally by Eyal Shenitzky)
Comment 15 rhev-integ 2017-06-26 05:16:40 EDT
(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)
Comment 16 rhev-integ 2017-06-26 05:16:46 EDT
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)
Comment 17 rhev-integ 2017-06-26 05:16:52 EDT
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)
Comment 18 rhev-integ 2017-06-26 05:16:57 EDT
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)
Comment 19 rhev-integ 2017-06-26 05:17:03 EDT
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)
Comment 25 Kevin Alon Goldblatt 2017-07-02 08:13:09 EDT
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
Comment 27 errata-xmlrpc 2017-07-06 03:32:08 EDT
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

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