Booting an instance from snapshot (which is an instance booted from Cinder volume) fails with: "Volume is smaller than the minimum size specified in image metadata."

[Kashyap Chamarthy]

Description
===========

Booting an instance from snapshot (which is an instance booted from Cinder volume) fails with:

    ERROR (BadRequest): Volume is smaller than the minimum size specified in
    image metadata. Volume size is 1073741824 bytes, minimum size is
    3221225472 bytes. (HTTP 400) (Request-ID:
    req-547c0339-0576-418f-a5a1-72d9ff114401)

[Source: Originally reported by <email address hidden> as a downstream bug report.]

I reproduced this issue with upstream Nova on a single-node DevStack. Details below:

Steps to reproduce
==================

(1) Create a new Nova flavor (`nova flavor-create <name> <id> <ram>
    <disk> <vcpus>`):

    $ nova flavor-create m1.test 6 256 3 1

(2) Create a Cinder volume (the UUID here is of
    cirros-0.3.4-x86_64-disk):

    $ cinder create --display-name cirr-vol1 \
        --image-id 577d309a-b9e8-48fa-b461-28b14e002b4d 1

(3) Boot an instance from the created volume the UUID below is of
    the the Cinder volume created above:

    $ nova boot --boot-volume 360f97a0-6588-46ae-b25a-e5687cc2c0e0 \
        --flavor 6 instance-boot-from-vol

(4) Create a snapshot of the instance we just booted:

    $ nova image-create --poll instance-boot-from-vol \
        snap-of-instance-boot-from-vol

(5) Enumerate Glance images to get the UUID of the snapshot created
    above:

    $ glance image-list | grep snap-of-instance-boot-from-vol \
        | awk '{print$2}'
    a8b8b3b1-1312-4ece-96b0-2216e4e2d075

(6) Boot an instance using the above snapshot UUID as the image:

    $ nova boot --flavor 6 --image a8b8b3b1-1312-4ece-96b0-2216e4e2d075
        instance-from-snap

Actual Results
==============

    $ nova boot --flavor 6 --image a8b8b3b1-1312-4ece-96b0-2216e4e2d075
        instance-from-snap
    ERROR (BadRequest): Volume is smaller than the minimum size specified in
    image metadata. Volume size is 1073741824 bytes, minimum size is
    3221225472 bytes. (HTTP 400) (Request-ID:
    req-547c0339-0576-418f-a5a1-72d9ff114401)

Expected Results
================

Booting an instance from snapshot of a Cinder volume should succeed

Environment
===========

When I reproduced this issue with upstream Nova on DevStack, I was on
these commits:
------------------------------------------------------------------------
cinder
1eef3c7 (Merge "NetApp: Add iterator handling to client library", 2016-05-26)
devstack
327f8d1 (Merge "Fix typo in local variable name in time_stop", 2016-05-27)
devstack-tar-installer-plugin
d2d9575 (Added .gitreview, 2016-04-21)
glance
24fae90 (Merge "Normalize the options use singele quotes", 2016-05-24)
keystone
0b65a96 (Merge "Add identity providers integration tests", 2016-05-26)
neutron
d320df5 (Merge "Don't load DNS integration in l3_router_plugin", 2016-05-26)
nova
784f88b (Merge "Updated from global requirements", 2016-05-27)
requirements
2d2d21d (Merge "Raise mock requirement to 2.0", 2016-05-26)
------------------------------------------------------------------------

[Kashyap Chamarthy (kashyapc)]

Matthew Booth has also reproduced this issue, and noting his comments from the downstream bug here:

-------------
I just reproduced this in devstack, and this looks like a real bug to me. The issue is the image metadata generated when creating the snapshot.

In my reproducer, I've created a volume from a cirros image with no min_disk. I booted a flavor with a 2G root disk, although obviously that root disk is not created when booting from volume. I then snapshotted the instance. The resulting image metadata in the snapshot contains:

min_disk | 2
min_ram | 0
size | 0

I assume that min_disk here has been copied from the flavor size. This is obviously bogus. I believe that when we create the snapshot metadata we should copy image metadata from the source, and set size to the actual size.

Just to clarify, in the above reproducer I think that the bug has occurred by the time the snapshot is created. That may mean that the bug is in the creation of the snapshot, or it may mean that some metadata copied during that process is already wrong and the bug happened even earlier.

A workaround would be to update the image metadata of the snapshot to set min_disk to 0.
-------------

[Dinesh Bhor (dinesh-bhor)]

I just reproduced this on nova:
commit 19476e80582cce34d455b4750241915bbe3b4503
Merge: fd0ebb6 a7dde84
Author: Jenkins <email address hidden>
Date: Wed Jun 1 13:06:43 2016 +0000

    Merge "verify api-ref os-migrations.inc"

It looks like it is taking the min_disk from the flavor given.

[John Garbutt (johngarbutt)]

if the volume is not big enough for the disk, the boot should fail. Am I missing something here?

[John Garbutt (johngarbutt)]

ah, seems like min_disk is set wrongly when you take a snapshot.

Current we use the flavor.root_gb, but in the boot form volume case, we need to instead use the size of the root volume, which could be very different from the flavor size.

[Chris Martin (cm876n)]

Yea that's correct. We most likely need some method specifically for BFV to take the min_disk size of the root volume instead.

[Chris Martin (cm876n)]

To clarify the min_disk isn't set wrong when taking the snapshot but before that. The min_disk is set to flavor.root_gb while the size is set to volume.size in the initial instance, however, the exception that would catch this actually occurs before the min_size is changed from 0 to whatever the flavor.root_gb value is which means if there is a discrepency (say a flavor of size 3 and volume of size 1) it won't be caught until the snapshot is created and we attempt to boot the snapshot since now the min_disk has already been set to 3 the exception is thrown. That is why the bug occurs on the booting of the snapshot.

[OpenStack Infra (hudson-openstack)]

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

[Matt Riedemann (mriedem)]

I think this is a duplicate of bug 1469179.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Christopher Martin (<email address hidden>) on branch: master
Review: https://review.openstack.org/364337