invalid volume when source image virtual size is bigger than the requested size

[Dafna Ron]

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.

[Russell Bryant (russellb)]

What driver are you using? What Nova version? Can you please provide more complete log output?

[Dafna Ron (dron-3)]

[root@cougar06 ~]# 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
[root@cougar06 ~]# rpm -qa |grep qeu
[root@cougar06 ~]# rpm -qa |grep qemu
qemu-img-rhev-0.12.1.2-2.408.el6.x86_64
gpxe-roms-qemu-0.9.7-6.9.el6.noarch
qemu-kvm-rhev-0.12.1.2-2.408.el6.x86_64
[root@cougar06 ~]#

there was no errors in the logs.
please let me know what you would like added

[Dafna Ron (dron-3)]

oh, and I am using gluster with following rpms:

[root@cougar06 ~]# rpm -qa |grep fuse
fuse-2.8.3-4.el6.x86_64
glusterfs-fuse-3.4.0.33rhs-1.el6rhs.x86_64
fuse-libs-2.8.3-4.el6.x86_64
[root@cougar06 ~]#

[Xavier Queralt (xqueralt-deactivatedaccount)]

Hi Dafna, I've tried to reproduce this using a fedora 20 image but it worked properly. Could you specify the image you used to create the volume so we can try to reproduce it?

Besides, where do you get the error you mention if not in the logs? Does it appear in the instance's console-log? Can you provide the full console-log from this instance and the libvirt.xml nova creates under /var/lib/nova/instances ?

Thanks

[Dafna Ron (dron-3)]

i am using a rhel image.

there is no console-log unfortunately. I see the error in the instance itself (screen shot attached).

instance log is also attached

[Xavier Queralt (xqueralt-deactivatedaccount)]

The problem appears to be in cinder when using the gluster or nfs drivers.

If the source image is bigger (considering the virtual size) than the target volume, those drivers will still copy the image into the volume and resize it to fit the requested size. The problem is with the resulting image after the resize, which won't look as a proper disk to the hypervisor.

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 <source image path> <volume path>
  - After this we will have a volume as big as the original image
4. qemu-img resize <volume path> <volume size>G
  - After this, if the image was bigger than the volume we might end up with a truncated and unusable image.

[Xavier Queralt (xqueralt-deactivatedaccount)]

The easiest solution that I can think of now is to make cinder fail when the image is bigger than the volume size (same as lvm does).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/52463

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/52463
Committed: http://github.com/openstack/cinder/commit/6e287c0f2bb7d4994d50f1763f412277e4dac6f7
Submitter: Jenkins
Branch: master

commit 6e287c0f2bb7d4994d50f1763f412277e4dac6f7
Author: Xavier Queralt <email address hidden>
Date: Tue Oct 22 20:37:53 2013 +0200

    Fail when image is bigger than the volume

    When creating a new volume from a qcow2 image stored in glance, we will
    be given the physical size of the image instead of the virtual size.
    Most drivers will convert that image to raw after downloading for
    resizing it to the requested volume size afterwards.

    If the virtual size of the image is bigger than the requested one, the
    resulting volume might end up being unusable after the resize even
    though the creation went good.

    This patch will make the volume creation fail if the virtual size of
    the image exceeds the one of the requested volume.

    Closes-Bug: #1235358
    Change-Id: I254cd9e3acf5d9eb7eb913b37d27a14e97568dec

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/56188

[Eric Harney (eharney)]

Changing summary as this doesn't appear to be specific to glusterfs, based on the fix.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/57879

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/57879
Committed: http://github.com/openstack/cinder/commit/c4db75abddbb72ac5f717f6a9266e078b69206a8
Submitter: Jenkins
Branch: master

commit c4db75abddbb72ac5f717f6a9266e078b69206a8
Author: Xavier Queralt <email address hidden>
Date: Fri Nov 22 10:39:37 2013 +0100

    Pass the size when fetching image in xenapi driver

    In commit 6e287c0f2bb7d4994d50f1763f412277e4dac6f7 the fetch_to_raw
    method was changed to accept the volume size so it can fail when the
    image doesn't fit in the destination volume. In this commit we also
    updated all the volume drivers to pass the volume size to that method so
    it could perform the check. The xenapi driver missed that change.

    This commit updates the xenapi driver to pass the volume size when
    fetching the image to enable the introduced check.

    Change-Id: I89bc4b3b1c1e6b06f5c529166cf9ffa1fe600c96
    Related-Bug: #1235358

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: stable/havana
Review: https://review.openstack.org/58785

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/56188
Committed: http://github.com/openstack/cinder/commit/c5cb131c5fbc8aa5c5992a81468dd30631d9c8e9
Submitter: Jenkins
Branch: stable/havana

commit c5cb131c5fbc8aa5c5992a81468dd30631d9c8e9
Author: Xavier Queralt <email address hidden>
Date: Tue Oct 22 20:37:53 2013 +0200

    Fail when image is bigger than the volume

    When creating a new volume from a qcow2 image stored in glance, we will
    be given the physical size of the image instead of the virtual size.
    Most drivers will convert that image to raw after downloading for
    resizing it to the requested volume size afterwards.

    If the virtual size of the image is bigger than the requested one, the
    resulting volume might end up being unusable after the resize even
    though the creation went good.

    This patch will make the volume creation fail if the virtual size of
    the image exceeds the one of the requested volume.

    Closes-Bug: #1235358
    Change-Id: I254cd9e3acf5d9eb7eb913b37d27a14e97568dec
    (cherry picked from commit 6e287c0f2bb7d4994d50f1763f412277e4dac6f7)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/58785
Committed: http://github.com/openstack/cinder/commit/704b72c09f6ffce83f3adc0024f6ca22e26f60bc
Submitter: Jenkins
Branch: stable/havana

commit 704b72c09f6ffce83f3adc0024f6ca22e26f60bc
Author: Xavier Queralt <email address hidden>
Date: Fri Nov 22 10:39:37 2013 +0100

    Pass the size when fetching image in xenapi driver

    In commit 6e287c0f2bb7d4994d50f1763f412277e4dac6f7 the fetch_to_raw
    method was changed to accept the volume size so it can fail when the
    image doesn't fit in the destination volume. In this commit we also
    updated all the volume drivers to pass the volume size to that method so
    it could perform the check. The xenapi driver missed that change.

    This commit updates the xenapi driver to pass the volume size when
    fetching the image to enable the introduced check.

    Change-Id: I89bc4b3b1c1e6b06f5c529166cf9ffa1fe600c96
    Related-Bug: #1235358
    (cherry picked from commit c4db75abddbb72ac5f717f6a9266e078b69206a8)

[Alan Pevec (apevec)]

Is there anything left for Nova here?