snapshot with boot from volume fails

Bug #1055076 reported by Vish Ishaya
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
High
Vish Ishaya

Bug Description

There is a specific code path to snaphsot instances that have been booted from a volume. Unfortunately the code path only works if the instance has been created from a snapshot.

Repro Steps

nova boot --image=<image-uuid> --flavor 1 --block_device_mapping vda=<volume-uuid> test
nova image-create <instance-uuid> test-image
nova boot --image=test-image --flavor 1 new

Result:

new instance fails to boot

Expected:

new nstance boots from a snapshot of the original volume

note that it works correctly if the instance is booted from a snapshot
(nova boot --image=<image-uuid> --flavor 1 --block_device_mapping vda=<snapshot-uuid>:snap test)

Changed in nova:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Vish Ishaya (vishvananda)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

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

Changed in nova:
milestone: none → folsom-rc2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/13541
Committed: http://github.com/openstack/nova/commit/9562ee3ce71301fa0e4de0c167d6cc1cf83ed9a6
Submitter: Jenkins
Branch: master

commit 9562ee3ce71301fa0e4de0c167d6cc1cf83ed9a6
Author: Vishvananda Ishaya <email address hidden>
Date: Sun Sep 23 16:17:35 2012 +0000

    Fixes snapshotting of instances booted from volume

    When an instance was booted from a volume, the block device mapping
    entry has volume_id set. If it was booted from a snapshot it has
    volume_id and snapshot_id set. When we snapshot the instance, it
    should be snapshotting the volume in both cases.

    This patch fixes the faulty logic that was causing snapshotting to
    only happen in the case the instance was booted from a snapshot.

    It also includes a (formerly failing) test to verify that the volume
    commands are actually called and the new snapshot is set properly.

    Fixes bug 1055076

    Change-Id: Icdd2ab7f3e2d43a0564aea132fe707a592fe4e75

Changed in nova:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (milestone-proposed)

Fix proposed to branch: milestone-proposed
Review: https://review.openstack.org/13577

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (milestone-proposed)

Reviewed: https://review.openstack.org/13577
Committed: http://github.com/openstack/nova/commit/88043d178001f17defc4a1a399dc709a208eb4c0
Submitter: Jenkins
Branch: milestone-proposed

commit 88043d178001f17defc4a1a399dc709a208eb4c0
Author: Vishvananda Ishaya <email address hidden>
Date: Sun Sep 23 16:17:35 2012 +0000

    Fixes snapshotting of instances booted from volume

    When an instance was booted from a volume, the block device mapping
    entry has volume_id set. If it was booted from a snapshot it has
    volume_id and snapshot_id set. When we snapshot the instance, it
    should be snapshotting the volume in both cases.

    This patch fixes the faulty logic that was causing snapshotting to
    only happen in the case the instance was booted from a snapshot.

    It also includes a (formerly failing) test to verify that the volume
    commands are actually called and the new snapshot is set properly.

    Fixes bug 1055076

    Change-Id: Icdd2ab7f3e2d43a0564aea132fe707a592fe4e75

Changed in nova:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: folsom-rc2 → 2012.2
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.