|
|
| Line 1: |
Line 1: |
| − | == 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 ===
| |
