On 10 July 2014 16:52, Matthew Booth <mbo...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
