qcow2 images size should match the virtual image size

[Giulio Fidente]

the image size of qcow2 images should match the virtual size reported by qemu-img not the actual data size

# glance image-show ff8f8fb3-76a3-47c0-bfc2-7bbbb9e46950
[...]
| size | 699592704 |
[...]

# qemu-img info /var/lib/glance/images/ff8f8fb3-76a3-47c0-bfc2-7bbbb9e46950
image: /var/lib/glance/images/ff8f8fb3-76a3-47c0-bfc2-7bbbb9e46950
file format: qcow2
virtual size: 6.0G (6442450944 bytes)
disk size: 667M
cluster_size: 65536

[Giulio Fidente (gfidente)]

I think there is small or no value in showing the actual data size. Thinking about a few scenario cases where the virtual size would be a more useful information to show:

1. to create a cinder volume from the image, it is after the virtual size which the volume should be sized
2. to learn about the guest disk size, it is the virtual size the interesting value
3. to check the quota allowance/usage, it is with the virtual size which we should compare

[John Bresnahan (jbresnah)]

I agree that having glance expose details of the VM is useful. Perhaps we should have a category of meta-data that shows such things. In this case a column 'image-size' or some such. Would that work?

There is some value in knowing the actual data size as it tells you how many bites actually need to be transferred and stored on the . I am concerned that legacy applications may already be making assumptions about what size means.

[John Bresnahan (jbresnah)]

Further this should be able to be folded into the import/export blueprint and sync workers bp described here:

https://wiki.openstack.org/wiki/Glance-new-upload-workflow

When an image is 'imported' such things as its vm size, disk format, container format, etc can be extracted/converted.

[Giulio Fidente (gfidente)]

note that naming is confusing, qemu-img will show as "virtual size" the disk size and as "disk size" the actual allocated size within the disk image

[Arnaud Legendre (arnaudleg)]

The blueprint https://blueprints.launchpad.net/openstack/?searchtext=split-image-size has been approved for Icehouse-3: this should address your concern.

Thanks

[Arnaud Legendre (arnaudleg)]

Back to my comment #5: The bp "split-image-size" only addresses one part of your concern. Please look at https://blueprints.launchpad.net/glance/+spec/introspection-of-images for what I think is missing to have this bug fixed.

[Giulio Fidente (gfidente)]

hi Arnaud, thanks for keepig this updated. I think split-image-size should do it so I'd move this into "implemented" given the blueprint is actually done.

[Eric Zhou (zyouzhou)]

Does anyone know if we have implemented that glance can show the virtual size of an image?

[Doug Fish (drfish)]

I've just become aware of this issue. In Horizon, when creating a volume the values for "size" and "min_disk" are checked. (for my future reference: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/volumes/forms.py#L130)

It seems to me that automatically populating the "min_disk" attribute would be an appropriate way to fix this issue without changing the semantics of the existing "size" attribute.

[Jin Liu (liujinbj)]

Hi Flavio,

I see this is scheduled in next, that means j3 codes will include fixing, right?

[Liam Haworth (liam-haworth)]

Is possible to have this changed to a high importance? It currently affects the flow of production set-ups and their end-users

[Flavio Percoco (flaper87)]

This bug is actually invalid now. We've added a virtual_size field that should be used to set the image virtual_size. As of Juno, it should be set manually. However, in Kilo, the new introspection task should be capable of doing this itself.

[yatin (yatinkarel)]

Nova fails to boot an instance when virtual_size of the image is larger than flavor(disk size) used to boot the instance. As virtual size (only size is checked) is not checked by nova scheduler to schedule instance any of the compute node. Once instance is scheduled then hypervisor of the scheduled compute node checks the virtual size of the image and if the virtual size is larger then the disk allocated, it fails to boot instance.
So, if virtual size matches the image size, then nova will not fail to boot instance because of such reasons. I also feel that this should be changed to high importance.

[yatin (yatinkarel)]

Hi Flavio,

Have you started working on this bug. If not started, i can start after clearing some of my doubts...

Thanks

[Flavio Percoco (flaper87)]

@yatin Hey, I think you might be confused with what this bug aimed to do. The bug proposed that the `size` field should match the `virtual_size` instead of the `size`. What we did to fix this was adding a new `virtual_size` field that would represent the `virtual_size` value in some of the images.

I don't think nova uses the `virtual_size` field but I should double check. That said, the `virtual_size` value is an independent field that has nothing to do with the `size` of the image. Therefore, I do not believe these 2 fields should match. If anything, the virtual_size should be as big or bigger than the image size.

[yatin (yatinkarel)]

@Flavio
Yeh, i know virtual_size field has been already added.
Also, you are right that nova don't use virtual size field, but currently at time of scheduling(it uses size field) and at time of instance launch(it uses virtual size returned by(qemu-img info <image>)) to check the size of image that is to be launched. I also agree that virtual_size should be as big or bigger than image size.
Also, what size(size or virtual_size) will be shown to user when user runs glance image-list or glance image-show. I think virtual_size should be shown, please correct me if i am wrong.

Thanks

[Qiu Yu (unicell)]

@yatin: you will be able to get `virtual_size` from `glance image-show` if you're using V2 API with Glance version >= Juno.

[yatin (yatinkarel)]

@Qiu Yu, Thanks i will check