Bug 1585454

Summary: [downstream clone - 4.2.4] Uploaded image: Virtual Size of qcow2 image is not reflected at guest OS level
Product: Red Hat Enterprise Virtualization Manager Reporter: RHV bug bot <rhv-bugzilla-bot>
Component: ovirt-engineAssignee: Daniel Erez <derez>
Status: CLOSED ERRATA QA Contact: Yosi Ben Shimon <ybenshim>
Severity: low Docs Contact:
Priority: unspecified    
Version: 4.1.11CC: derez, ebenahar, lsurette, rbalakri, Rhev-m-bugs, srevivo, tnisan, ykaul
Target Milestone: ovirt-4.2.4Keywords: ZStream
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.2.4 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1576862 Environment:
Last Closed: 2018-06-27 10:02:42 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:
Bug Depends On: 1576862    
Bug Blocks:    

Description RHV bug bot 2018-06-03 07:05:26 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1576862 +++
======================================================================

Description of problem:

Disk size of VM matches original Virtual Size of qcow2 image instead of Size(GB) we are defining while uploading image from "Disk Options".

Version-Release number of selected component (if applicable):
rhevm-4.1.11.2-0.1.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Upload qcow2 format image using upload option from "Disks" tab.
2. Boot VM using this disk.
3. Check disk size of VM.

Actual results:
Disk size is of (actual) virtual size of uploaded qcow2 format image

Expected results:
Disk of VM should be of virtual size of disk allocated via Size(GB) from "Disk Options" while uploading disk


Additional info:
Extending size of disk from rhv manager portal will correctly reflect the disk size inside guest.

No issue with raw format as Size(GB) under Disk Options matches device size of VM.

(Originally by Ameya Charekar)

Comment 4 RHV bug bot 2018-06-03 07:05:40 UTC
So essentially, we are not extending the disk during upload? yet another reason why we should NOT ask for disk size during upload, IMHO.

(Originally by Yaniv Kaul)

Comment 5 RHV bug bot 2018-06-03 07:05:44 UTC
(In reply to Yaniv Kaul from comment #3)
> So essentially, we are not extending the disk during upload? yet another
> reason why we should NOT ask for disk size during upload, IMHO.

The suggested fix is to set the disk size automatically (in upload disk dialog), using size information from the qcow header (or file size for raw images).

(Originally by Daniel Erez)

Comment 7 RHV bug bot 2018-06-03 07:05:52 UTC
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops@redhat.com

(Originally by rhv-bugzilla-bot)

Comment 9 Yosi Ben Shimon 2018-06-12 08:03:41 UTC
Tested using:
ovirt-engine-4.2.4.2-0.1.el7_3.noarch

Actual result:
Uploaded image with virtual size of 10G and actual size of ~210MB.
After booting the vm from the disk, the virtual and actual size (both from WebAdmin and API) were ~210MB and 10G respectively.

Moving to VERIFIED.

Comment 11 errata-xmlrpc 2018-06-27 10:02:42 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/RHSA-2018:2071

Comment 12 Franta Kust 2019-05-16 13:04:52 UTC
BZ<2>Jira Resync

Comment 13 Daniel Gur 2019-08-28 13:12:26 UTC
sync2jira

Comment 14 Daniel Gur 2019-08-28 13:16:38 UTC
sync2jira