Bug 1576862 - Uploaded image: Virtual Size of qcow2 image is not reflected at guest OS level
Summary: Uploaded image: Virtual Size of qcow2 image is not reflected at guest OS level
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.11
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ovirt-4.3.0
: 4.3.0
Assignee: Daniel Erez
QA Contact: Yosi Ben Shimon
URL:
Whiteboard:
Depends On:
Blocks: 1585454
TreeView+ depends on / blocked
 
Reported: 2018-05-10 15:04 UTC by Ameya Charekar
Modified: 2020-08-03 15:26 UTC (History)
7 users (show)

Fixed In Version: ovirt-engine-4.3.0_alpha
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1585454 (view as bug list)
Environment:
Last Closed: 2019-05-08 12:37:35 UTC
oVirt Team: Storage
Target Upstream Version:
lsvaty: testing_plan_complete-


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1085 None None None 2019-05-08 12:37:56 UTC
oVirt gerrit 91183 master MERGED webadmin: upload image - set disk size 2020-02-25 11:07:20 UTC
oVirt gerrit 91227 ovirt-engine-4.2 MERGED webadmin: upload image - set disk size 2020-02-25 11:07:20 UTC

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


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