Jump to: navigation, search

Difference between revisions of "Obsolete:TheBetterPathToLiveMigration"

(The Better Path To Live Migration)
(Rationale)
Line 1: Line 1:
 
== The Better Path To Live Migration ==
 
== The Better Path To Live Migration ==
 +
  
 
=== Rationale ===
 
=== Rationale ===
 +
 +
The current code path for resizing and live migration is what you could call ''hairy'' in that the state-machine that is used to accomplish these 2 types of tasks (which are by there very nature extremely similar) is itself complex and could benefit from rework around a more organized state-machine which would be orchestrated by an external entity, of which said external entity can handle the intricacies of cross-compute communication as well as state-machine transitions and associated failure scenarios. 
 +
 +
=== Definitions ===
 +
 +
;Live migration
 +
: Moving a instance (and associated) resources from one compute node to another compute node while the instance is still running.
 +
;Resizing
 +
: Moving a instance (and associated) resources from one compute node to another compute node which can support the instance  with re-sized  capabilities (more/less VCPU for example)
  
 
=== Current path ===
 
=== Current path ===

Revision as of 00:20, 30 April 2013

The Better Path To Live Migration

Rationale

The current code path for resizing and live migration is what you could call hairy in that the state-machine that is used to accomplish these 2 types of tasks (which are by there very nature extremely similar) is itself complex and could benefit from rework around a more organized state-machine which would be orchestrated by an external entity, of which said external entity can handle the intricacies of cross-compute communication as well as state-machine transitions and associated failure scenarios.

Definitions

Live migration
Moving a instance (and associated) resources from one compute node to another compute node while the instance is still running.
Resizing
Moving a instance (and associated) resources from one compute node to another compute node which can support the instance with re-sized capabilities (more/less VCPU for example)

Current path

The problems

Better path

The solutions

Migration from current to better