Instance doesn't boot with image created after volume swap

Bug #1646698 reported by Hussain Chachuliya
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
New
Undecided
Unassigned

Bug Description

Consider you have two volumes, say vol_1 and vol_2, one created using an AMI image and another with a QCOW2 image respectively and if you create an instance using boot-from-volume with vol_1, then after swapping volumes vol_1 with vol_2, it should be possible to boot new instance with image created from vol_2.

Steps to reproduce:

1. Create a volume with image disk format type AMI.
    cinder create 1 --name ami_1 --image-id 568b9926-6ec6-4251-8853-58bc949454c9

2. Create another volume with image disk format type QCOW2.
    cinder create 1 --name qcow2_2 --image-id ab18becb-1262-45da-a1c0-053759a182da

3. Observe the volumes created in step 1 and 2.
    cinder list
+--------------------------------------+----------------+-------------------+------+-------------+----------+--------------------------------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+----------------+-------------------+------+-------------+----------+--------------------------------------+
| 00f13c2a-96b8-44ac-9565-a67006c4be20 | available | qcow2_2 | 1 | lvmdriver-1 | true | |
| 5cf36f5f-4ccd-463c-a208-501433d0b3b6 | available | ami_1 | 1 | lvmdriver-1 | true | |
+--------------------------------------+----------------+-------------------+------+-------------+----------+--------------------------------------+

4. Boot an instance from volume created in step 1.
    nova boot test --flavor 1 --boot-volume 5cf36f5f-4ccd-463c-a208-501433d0b3b6

5. When the instance is up and running, swap the current volume with volume created in step 2.
    nova volume-update test 5cf36f5f-4ccd-463c-a208-501433d0b3b6 00f13c2a-96b8-44ac-9565-a67006c4be20

6. After the volumes are swapped, reboot the instance.
    nova reboot test

7. Verify that the instance is up and running from the console's tab under Instances section on Dashboard and then delete the instance to make volume qcow2_2 available.
    nova delete test

8. After the volume qcow2_2 becomes available, create an image from it.
    cinder upload-to-image qcow2_2 new_image

9. Observe the image created in step 8.
    glance image-list
+--------------------------------------+---------------------------------+
| ID | Name |
+--------------------------------------+---------------------------------+
| d7cb2f17-1af6-4c7f-8570-f49085adbf35 | cirros-0.3.0-x86_64-kernel |
| d937a550-6956-4c48-a774-31333eda540d | cirros-0.3.0-x86_64-ramdisk |
| 568b9926-6ec6-4251-8853-58bc949454c9 | cirros-0.3.0-x86_64-uec |
| ab18becb-1262-45da-a1c0-053759a182da | cirros-0.3.2-x86_64-disk |
| b8094bcd-83d7-4198-bcc0-112cf51e26cb | new_image |
+--------------------------------------+---------------------------------+

10. Boot an instance using the image created in step 8.
    nova boot test_new --flavor 1 --image b8094bcd-83d7-4198-bcc0-112cf51e26cb

11. Go to Dashboard and observe the 'Console' tab under Instances section for the instance created in step 10.
 It shows,

 Booting from Hard Disk...
 Boot failed: not a bootable disk

 No bootable device.

================
Expected result:
================
The instance should boot successfully along with all the data intact.

Changed in cinder:
assignee: nobody → Hussain Chachuliya (hussainchachuliya)
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote : Bug Assignee Expired

Unassigning due to no activity for > 6 months.

Changed in cinder:
assignee: Hussain Chachuliya (hussainchachuliya) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.