Open Stack

On 10 July 2014 16:52, Matthew Booth <mbooth at redhat.com> wrote:
> Currently we create a rescue instance by creating a new VM with the
> original instance's image, then adding the original instance's first
> disk to it, and booting. This means we have 2 VMs, which we need to be
> careful of when cleaning up. Also when suspending, and probably other
> edge cases. We also don't support:
>
> * Rescue images other than the instance's creation image
> * Rescue of an instance which wasn't created from an image
> * Access to cinder volumes from a rescue instance
>
> I've created a dirty hack which, instead of creating a new VM, attaches
> the given rescue image to the VM and boots from it:
>
> https://review.openstack.org/#/c/106078/

I do worry about different drivers having such radically different
implementation approaches.

Currently rescue only attaches the root disk to the rescue image.
Having a separate VM does side step having to work out where to
reattach all the disks when you boot up the original VM, as you
haven't modified that. But there are plans to change that here:
http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/rescue-attach-all-disks.rst

You can now specify and image when you go into rescue mode:
http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/juno/allow-image-to-be-specified-during-rescue.rst

I guess the rescue image could technically change how the VM boots, or
what hardware it has attached, so you might end up making so many
"tweaks" to the original VM that you might want to just create a new
VM, then through way those changes when you restore the original VM.

It feels a lot like we need to better understand the use cases for
this feature, and work out what we need in the long term.

> Does this seem a reasonable way to go?

Maybe, but I am not totally keen on making it such a different
implementation to all the other drivers. Mostly for the sake of people
who might run two hypervisors in their cloud, or people who support
customers running various hypervisors.

John