Difference between revisions of "LiveMigrateNonActiveStates"
(→Extending live-migration to instances in non-ACTIVE states) |
m (→Extending live-migration to instances in non-ACTIVE states) |
||
Line 1: | Line 1: | ||
=== Extending live-migration to instances in non-ACTIVE states === | === Extending live-migration to instances in non-ACTIVE states === | ||
− | ''Why restrict live-migration feature to only active instances?'' | + | '''Why restrict live-migration feature to only active instances?''' |
I believe that there are two parts to an answer to this question: technical and usability. | I believe that there are two parts to an answer to this question: technical and usability. | ||
Line 10: | Line 10: | ||
# 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. | # 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. | ||
# (TODO:) | # (TODO:) | ||
+ | |||
====Usability issues==== | ====Usability issues==== | ||
# 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. | # 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. | ||
# (TODO:) | # (TODO:) | ||
+ | |||
====A possible solution==== | ====A possible solution==== | ||
Line 20: | Line 22: | ||
# In post live-migration at destination, take the VM to the required state by using the vm_state as a hint. | # In post live-migration at destination, take the VM to the required state by using the vm_state as a hint. | ||
# (TODO:) | # (TODO:) | ||
+ | |||
====The usability issue may be handled in one of the following ways.==== | ====The usability issue may be handled in one of the following ways.==== | ||
Line 26: | Line 29: | ||
# Leave the API unchanged | # Leave the API unchanged | ||
# (TODO:) | # (TODO:) | ||
+ | |||
We propose that we don't 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. The onus is on an operator to choose an appropriate instance to be migrated. If a non-active instance is chosen we might as well try our best to migrate it. | We propose that we don't 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. The onus is on an operator to choose an appropriate instance to be migrated. If a non-active instance is chosen we might as well try our best to migrate it. |
Revision as of 13:42, 7 February 2014
Contents
Extending live-migration to instances in non-ACTIVE states
Why restrict live-migration feature to only active instances?
I believe that there are two parts to an answer to this question: technical and usability.
The rest of the text is based on a libvirt/kvm installation with block-migration. It is possible that Xen and other hypervisors may have different issues.
Technical issues
- 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.
- (TODO:)
Usability issues
- 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.
- (TODO:)
A possible solution
- Bring all non-active instances to 'PAUSED' state. This will require shutoff instances to be started as PAUSED.
- Migrate the instance and leave it at PAUSED state.
- In post live-migration at destination, take the VM to the required state by using the vm_state as a hint.
- (TODO:)
The usability issue may be handled in one of the following ways.
- Add an extra option to differentiate from the current live-migration. (Eg: --all-states)
- Add a different API entry point
- Leave the API unchanged
- (TODO:)
We propose that we don't 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. The onus is on an operator to choose an appropriate instance to be migrated. If a non-active instance is chosen we might as well try our best to migrate it.
States to be supported
- PAUSED
- STOPPED
- SUSPENDED
- RESCUED