yahoo-eng-team team mailing list archive

[Alan Pevec <1246327@xxxxxxxxxxxxxxxxxx>]

** Changed in: nova/havana
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1246327

Title:
  the snapshot of a volume-backed instance cannot be used to boot a new
  instance

Status in OpenStack Compute (Nova):
  Fix Released
Status in OpenStack Compute (nova) havana series:
  Fix Released

Bug description:
  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.

  The steps to reproduce are:

  $ 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

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

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

  $ nova image-create test-instance test-snap

  This will create an 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}] |

  When we try latter 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:

  $ 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)

  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1246327/+subscriptions