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:
https://bugs.launchpad.net/nova/+bug/1235358
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.
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.
Oh, and I'm moving this to the cinder component.
Changing summary as this is being fixed as a general Cinder operation rather than just for GlusterFS.
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/ .
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.
Eric, any update on this one?
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.
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