Bug 1015645 - invalid volume when source image virtual size is bigger than the requested size
invalid volume when source image virtual size is bigger than the requested size
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder (Show other bugs)
4.0
x86_64 Linux
high Severity high
: z1
: 4.0
Assigned To: Eric Harney
Tzach Shefi
: TestOnly, ZStream
Depends On: 1045428
Blocks: 984918
  Show dependency treegraph
 
Reported: 2013-10-04 12:57 EDT by Dafna Ron
Modified: 2016-04-26 19:44 EDT (History)
9 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-23 09:24:18 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1235358 None None None Never
OpenStack gerrit 52463 None None None Never

  None (edit)
Description Dafna Ron 2013-10-04 12:57:23 EDT
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 12:59:44 EDT
https://bugs.launchpad.net/nova/+bug/1235358
Comment 4 Xavier Queralt 2013-10-16 17:50:19 EDT
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 18:15:55 EDT
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 08:44:42 EDT
Oh, and I'm moving this to the cinder component.
Comment 8 Eric Harney 2013-11-21 16:11:22 EST
Changing summary as this is being fixed as a general Cinder operation rather than just for GlusterFS.
Comment 9 Eric Harney 2013-11-27 09:46:34 EST
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 09:58:32 EST
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 03:50:20 EST
Eric, any update on this one?
Comment 13 Tzach Shefi 2014-01-16 11:52:31 EST
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 12:20:39 EST
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.