Jump to: navigation, search

Difference between revisions of "LiveMigrateNonActiveStates"

(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...")
 
(→‎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 ===
  
−
Do we need to restrict live-migration capability to only active instances?
+
''Why restrict live-migration feature to only active instances?''
  
−
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.  
  
−
Technical issues.
+
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.
  
−
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.
+
====Technical issues====
−
2. (TODO:)
+
# 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:)
  
−
Usability issues.
+
====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:)
  
−
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.
+
====The usability issue may be handled in one of the following ways.====
−
2. (TODO:)
+
# 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:)
  
−
Specific hypervisor solution.
+
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.
  
−
Looking at libvirt/kvm it may be possible to overcome the above issues. Other hypervisor issues (TODO)
+
==== States to be supported ====
  
−
1. Bring all non-active instances to 'PAUSED' state. This will require shutoff instances to be started as PAUSED.
+
# PAUSED
−
2. Migrate the instance and leave it at PAUSED state.
+
# STOPPED
−
3. In post live-migration at destination, take the VM to the required state by using the vm_state as a hint.
+
# SUSPENDED
−
4. (TODO:)
+
# RESCUED
−
 
 
−
 
 
−
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.
 

Revision as of 13:34, 7 February 2014

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

  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:)

A possible solution

  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 may 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:)

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

  1. PAUSED
  2. STOPPED
  3. SUSPENDED
  4. RESCUED
Retrieved from "https://wiki.openstack.org/w/index.php?title=LiveMigrateNonActiveStates&oldid=41605"