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):
2013.2

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-192.168.122.2:3260-iscsi-iqn.2010-10.org.openstack:volume-cb6d4406-1c66-4f9a-9fd8-7e246a3b93b7-lun-1\", \"target_iqn\": \"iqn.2010-10.org.openstack:volume-cb6d4406-1c66-4f9a-9fd8-7e246a3b93b7\", \"target_portal\": \"192.168.122.2:3260\", \"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