Bug 1026325 - the snapshot of a volume-backed instance cannot be used to boot a new instance
the snapshot of a volume-backed instance cannot be used to boot a new instance
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: rc
: 4.0
Assigned To: Xavier Queralt
Ami Jeain
: 1024430 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2013-11-04 07:37 EST by Xavier Queralt
Modified: 2014-06-18 03:00 EDT (History)
8 users (show)

See Also:
Fixed In Version: openstack-nova-2013.2-6.el6ost
Doc Type: Bug Fix
Doc Text:
Cause: During the boot process, snapshots of volume-backed instances were handled incorrectly, causing nova to treat them as normal images. Consequence: An incorrect boot occurred and the snapshots of volume-backed instances could not be used to boot a new instance. Also, the connection information of the original instance was kept in the snapshot and caused any new instance to try to use the original volume instead of its snapshot. Fix: Conflicts with the boot index stored in the image properties have been resolved. Result: Snapshots of volume-backed instances are properly handled to allow normal instance booting.
Story Points: ---
Clone Of:
Last Closed: 2013-12-19 19:33:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1246327 None None None Never
OpenStack gerrit 54633 None None None Never
OpenStack gerrit 54634 None None None Never

  None (edit)
Description Xavier Queralt 2013-11-04 07:37:20 EST
Description of problem:
After the changes in the block device mappings introduced for Havana, if we try to create an snapshot of a volume-backed instance the resulting image cannot be used to boot a new instance due to conflicts with the bootindex between the block_device_mapping stored in the image properties and the current image.

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

How reproducible:

Steps to Reproduce:

1. glance image-create --name f20 --disk-format qcow2 --container-format bare --min-disk 2 --is-public True --min-ram 512 --copy-from http://download.fedoraproject.org/pub/fedora/linux/releases/test/20-Alpha/Images/x86_64/Fedora-x86_64-20-Alpha-20130918-sda.qcow2

2. cinder create --image-id <uuid of the new image> --display-name f20 2

3. nova boot --boot-volume <uuid of the new volume> --flavor m1.tiny test-instance

4. nova image-create test-instance test-snap

This will create a snapshot of the volume and an image in glance with a block_device_mapping containing the snapshot_id and all the other values from the original block_device_mapping (id, connection_info, instance_uuid, ...):

| Property 'block_device_mapping' | [{"instance_uuid": "989f03dc-2736-4884-ab66-97360102d804", "virtual_name": null, "no_device": null, "connection_info": "{\"driver_volume_type\": \"iscsi\", \"serial\": \"cb6d4406-1c66-4f9a-9fd8-7e246a3b93b7\", \"data\": {\"access_mode\": \"rw\", \"target_discovered\": false, \"encrypted\": false, \"qos_spec\": null, \"device_path\": \"/dev/disk/by-path/ip-\", \"target_iqn\": \"iqn.2010-10.org.openstack:volume-cb6d4406-1c66-4f9a-9fd8-7e246a3b93b7\", \"target_portal\": \"\", \"volume_id\": \"cb6d4406-1c66-4f9a-9fd8-7e246a3b93b7\", \"target_lun\": 1, \"auth_password\": \"wh5bWkAjKv7Dy6Ptt4nY\", \"auth_username\": \"oPbN9FzbEPQ3iFpPhv5d\", \"auth_method\": \"CHAP\"}}", "created_at": "2013-10-30T13:18:57.000000", "snapshot_id": "f6a25cc2-b3af-400b-9ef9-519d28239920", "updated_at": "2013-10-30T13:19:08.000000", "device_name": "/dev/vda", "deleted": 0, "volume_size": null, "volume_id": null, "id": 3, "deleted_at": null, "delete_on_termination": false}] |

5. nova boot --image test-snap --flavor m1.nano test-instance2
ERROR: Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid. (HTTP 400) (Request-ID: req-3e502a29-9cd3-4c0c-8ddc-a28d315d21ea)

When we try to use this image to boot a new instance, the API won't let us because both, the device in the image bdm and the image (which is empty) are considered to be the boot device:

Actual results:

Expected results:

Additional info:

If we check the internal flow we can see that nova considers the image to be the boot device even thought the image itself doesn't define any local disk but only a block_device_mapping pointing to the snapshot.

To be able to generate proper images from volume-backed instances we should:
 1. copy only the relevant keys from the original block_device_mapping to prevent duplicities in DB
 2. prevent nova from adding a new block device for the image if this one doesn't define any local disk
Comment 3 Xavier Queralt 2013-11-20 04:33:48 EST
*** Bug 1024430 has been marked as a duplicate of this bug. ***
Comment 5 Udi 2013-12-18 03:45:04 EST
Fixed in openstack-nova-2013.2-10.el6ost.noarch
Comment 7 errata-xmlrpc 2013-12-19 19:33:55 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.


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