Bug 1517308 - Images virtual size is unnecessarily big
Summary: Images virtual size is unnecessarily big
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Build
Version: 5.9.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: GA
: cfme-future
Assignee: Satoe Imaishi
QA Contact: Jaroslav Henner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-24 15:28 UTC by Jaroslav Henner
Modified: 2021-07-30 08:01 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-12 19:18:12 UTC
Category: ---
Cloudforms Team: Openstack
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 977028 0 high CLOSED Root partition does not get resized to the available space 2021-02-22 00:41:40 UTC

Internal Links: 977028

Description Jaroslav Henner 2017-11-24 15:28:25 UTC
Description of problem:
The image virtual size is unnecessarily big, requiring big flavor to boot in openstack. Because the quemu image can be grown, but not shrink, it would be better to just use smaller virtual size and let the user grow the this if needed.

Version-Release number of selected component (if applicable):
cfme-rhos-5.9.0.9-1.x86_64.qcow2


How reproducible:
always


Steps to Reproduce:
qemu-img info /tmp/foo
image: /tmp/foo
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 1.1G


Actual results:


Expected results:
Disk size ~10 should be enough for everybody. If it is too small, it can be grown.

Additional info:

Comment 5 Dave Johnson 2017-12-07 15:09:11 UTC
Satoe, can you confirm how the image is packaged please?  It sounds like it is THIN if the image size is 1.1GB and the virtual size is 40GB, is that correct?  This smell like environmental issue.

Comment 11 Jaroslav Henner 2020-01-03 16:01:58 UTC
This bug is closed, but anyway:

virtual size is the disk size of the image which will be read by VM
disk size is the real size which hold in the host file system

I wanted to change the virtual size because at that time this value was what Heat was looking at. If someone wants to increase that value, it is not a problem (I think one can use qemu-img resize  for that.) I think there was though no way to make that value smaller. Today it seems to be possible but still it is more difficult to shrink than grow as data need to be reallocated from the tail of the "allocated" virtual space.


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