Bug 1015645 - invalid volume when source image virtual size is bigger than the requested size
Summary: invalid volume when source image virtual size is bigger than the requested size
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: 4.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: z1
: 4.0
Assignee: Eric Harney
QA Contact: Tzach Shefi
URL:
Whiteboard:
Depends On: 1045428
Blocks: 984918
TreeView+ depends on / blocked
 
Reported: 2013-10-04 16:57 UTC by Dafna Ron
Modified: 2019-09-09 15:34 UTC (History)
8 users (show)

Fixed In Version: openstack-cinder-2013.2.1-1.el6ost
Doc Type: Bug Fix
Doc Text:
Previously, image size wasn't checked prior to copying into a volume. If the image was too large to fit on the volume, the image data copy or volume boot would fail, depending on the driver. With this update, the virtual image size is checked before the copy process is started. The result is that volume create-from-image fails upfront in the process, and before unexpected results are produced.
Clone Of:
Environment:
Last Closed: 2014-01-23 14:24:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
compuet log (2.35 MB, application/x-gzip)
2013-10-04 16:57 UTC, Dafna Ron
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1235358 0 None None None Never
OpenStack gerrit 52463 0 None None None Never
Red Hat Product Errata RHBA-2014:0046 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform 4 Bug Fix and Enhancement Advisory 2014-01-23 00:51:59 UTC

Description Dafna Ron 2013-10-04 16:57:23 UTC
Created attachment 807861 [details]
compuet log

Description of problem:

I created a volume from an image and booted an instance from it
when instance boots I get this: 'selected cylinder exceeds maximum supported by bios'
If I boot an instance from the same image I can boot with no issues so its just booting from the volume.

Version-Release number of selected component (if applicable):

[root@cougar06 qemu(keystone_admin)]# rpm -qa |grep nova
openstack-nova-scheduler-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-compute-2013.2-0.24.rc1.el6ost.noarch
python-novaclient-2.15.0-1.el6ost.noarch
python-nova-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-api-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-console-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-conductor-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-novncproxy-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-network-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-cert-2013.2-0.24.rc1.el6ost.noarch
openstack-nova-common-2013.2-0.24.rc1.el6ost.noarch

How reproducible:

not sure - happens 100% with the images I am using 

Steps to Reproduce:
1. create an image 
2. create a volume from the image
3. boot an instance from the volume 

Actual results:

we get 'selected cylinder exceeds maximum supported by bios' error when the instance boots 

Expected results:

we should be able to boot from the image 

Additional info:

Comment 1 Dafna Ron 2013-10-04 16:59:44 UTC
https://bugs.launchpad.net/nova/+bug/1235358

Comment 4 Xavier Queralt 2013-10-16 21:50:19 UTC
The problem seems to be with the glusterfs cinder driver which will let you create a volume smaller than the source image size. This volume, after the image has been copied in it, is unusable as it will miss part of the data from the original image.

In your case, you were using a qcow2 RHEL image of 1.9GB on disk and 6.0GB of virtual size. The size reported by glance is the one of 1.9GB so it is obvious that a volume of 2GB would be enough to fit the image (value suggested by horizon too).

I've used the same image as you as the source for two volumes: one of 2GB and another of 10GB. The first one won't be able to boot and will fail with the reported error (or "Error 18", which is the same) but I've been able to boot using the second one.

Other storage drivers like lvm will fail while copying the image into the volume if this can't fit the whole image (counting the virtual size). We could do the same for gluster to prevent creating an invalid volume. On the other hand, it would make sense to change glance so it reports the virtual size instead of the physical size.

Comment 5 Xavier Queralt 2013-10-16 22:15:55 UTC
Those are the commands called by the gluster (and nfs) driver when creating a volume from an image:

1. truncate -s <volume size>G <volume path>
2. download the image to <image path>
3. qemu-img convert -O raw <image path> <volume path>
  - After this we will have a volume as big as the original image
4. qemi-img resize <volume path> <volume size>G
  - After this, if the image is bigger than the volume we might end up with a truncated and unusable image.

Comment 6 Xavier Queralt 2013-10-17 12:44:42 UTC
Oh, and I'm moving this to the cinder component.

Comment 8 Eric Harney 2013-11-21 21:11:22 UTC
Changing summary as this is being fixed as a general Cinder operation rather than just for GlusterFS.

Comment 9 Eric Harney 2013-11-27 14:46:34 UTC
Don't we also need to backport https://review.openstack.org/#/c/57879/ to take this backport?

See comments at https://review.openstack.org/#/c/56188/ .

Comment 10 Xavier Queralt 2013-11-27 14:58:32 UTC
Well, the patch you mention is only for the xenapi driver which I don't know if we support. Anyway, you can find the backport in gerrit now.

Comment 11 Ayal Baron 2013-12-18 08:50:20 UTC
Eric, any update on this one?

Comment 13 Tzach Shefi 2014-01-16 16:52:31 UTC
RHEL 6.5 
openstack-cinder-2013.2.1-4.el6ost.noarch
Semi-dist setup

Verified as fixed, checked on both:
 Horizon - volume size is automatically expanded to fit image size. 
 CLI - error notice indicates given volume size too low.

Comment 17 Lon Hohberger 2014-02-04 17:20:39 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://rhn.redhat.com/errata/RHBA-2014-0046.html


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