Jump to: navigation, search

LiveMigrateNonActiveStates

Revision as of 13:23, 7 February 2014 by Parthipan (talk | contribs) (Created page with "=== Extending live-migration to instances in non-ACTIVE states === Do we need to restrict live-migration capability to only active instances? There are two parts to an answe...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Extending live-migration to instances in non-ACTIVE states

Do we need to restrict live-migration capability to only active instances?

There are two parts to an answer to this question: technical and usability.

Technical issues.

1. It's not possible to migrate when there's no running hypervisor process running. For example, in a libvirt/kvm setup, if an instance is shutoff, there's no kvm process and a migrate job cannot be sent. 2. (TODO:)


Usability issues.

1. The term live migration suggests a running instance and users may expect an error returned as per the API. This also covers backward compatibilty issues. 2. (TODO:)

Specific hypervisor solution.

Looking at libvirt/kvm it may be possible to overcome the above issues. Other hypervisor issues (TODO)

1. Bring all non-active instances to 'PAUSED' state. This will require shutoff instances to be started as PAUSED. 2. Migrate the instance and leave it at PAUSED state. 3. In post live-migration at destination, take the VM to the required state by using the vm_state as a hint. 4. (TODO:)


The usability issue can be handled in one of the following ways.

1. Add an extra option to differentiate from the current live-migration. (Eg: --all-states) 2. Add a different API entry point 3. Leave the API unchanged 4. (TODO:)

It's perhaps preferable to not change the API at all (option 3). The "--all-states" forces all states to be supported at once. Also since these are non-active instances, it might have less impact on user experience.