Bug 1576862

Summary: Uploaded image: Virtual Size of qcow2 image is not reflected at guest OS level
Product: Red Hat Enterprise Virtualization Manager Reporter: Ameya Charekar <achareka>
Component: ovirt-engineAssignee: Daniel Erez <derez>
Status: CLOSED ERRATA QA Contact: Yosi Ben Shimon <ybenshim>
Severity: low Docs Contact:
Priority: low    
Version: 4.1.11CC: derez, ebenahar, lsurette, mtessun, Rhev-m-bugs, srevivo, tnisan
Target Milestone: ovirt-4.3.0Keywords: ZStream
Target Release: 4.3.0Flags: lsvaty: testing_plan_complete-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.3.0_alpha Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1585454 (view as bug list) Environment:
Last Closed: 2019-05-08 12:37:35 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:
Bug Depends On:    
Bug Blocks: 1585454    

Description Ameya Charekar 2018-05-10 15:04:30 UTC
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.

Comment 3 Yaniv Kaul 2018-05-13 07:52:12 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.

Comment 4 Daniel Erez 2018-05-13 10:40:52 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).

Comment 6 RHV bug bot 2018-05-24 23:53:20 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

Comment 8 Elad 2018-08-21 12:42:09 UTC
Verify according to https://bugzilla.redhat.com/show_bug.cgi?id=1585454#c9

Comment 9 Yosi Ben Shimon 2018-08-22 14:28:03 UTC
Tested using:
ovirt-engine-4.3.0-0.0.master.20180815091554.gitd5455ea.el7.noarch
ovirt-imageio-proxy-1.4.2-0.201808131405.gitec63551.el7.centos.p.noarch

Uploaded image (local):

$ qemu-img info temp_img.qcow2 
image: temp_img.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 50M
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16

On storage after upload:
$ qemu-img info 213ac123-8f5a-46df-b4a6-16e39bf2f3a0
image: 213ac123-8f5a-46df-b4a6-16e39bf2f3a0
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 246M
cluster_size: 65536
Format specific information:
    compat: 0.10
    refcount bits: 16

From database before & after attaching to VM (and boot):

engine=# select image_guid,size from all_disks_including_snapshots where vm_names ='test_vm';
              image_guid              |    size     
--------------------------------------+-------------
 213ac123-8f5a-46df-b4a6-16e39bf2f3a0 | 10737418240


Moving to VERIFIED

Comment 10 RHV bug bot 2018-12-10 15:13:24 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

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

Comment 11 RHV bug bot 2019-01-15 23:35:52 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{'rhevm-4.3-ga': '?'}', ]

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

Comment 13 errata-xmlrpc 2019-05-08 12:37:35 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-2019:1085

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

Comment 15 Daniel Gur 2019-08-28 13:17:11 UTC
sync2jira