Difference between revisions of "LiveMigration"

Latest revision as of 23:31, 17 February 2013

Launchpad Entry: NovaSpec:bexar-migration-live
Created: 2010-10-20
Contributors: Kei Masumoto, Muneyuki Noguchi, Masanori Itoh, Tushar Patil

Note

On the 2nd Design Summit, please see: http://etherpad.openstack.org/LiveMigration
Please see attached PPT presented at the Bexar Design Summit and the above etherpad note.
Please see notes in the Dependency section.

Summary

Add a capability for migrating a running VM from one host to another host transparently to applications and any external entity interacting with such applications on the cloud server without taking down the cloud server and with a very negligible downtime.

Dependency

A Special Note:

This blueprint, bexar-migration-live, depends on bexar-network-service in the following sense.

After we have bexar-migration-live, we can attach multiple NICs to a VM. Live Migration feature should support migrating network connectivity together with the VM. In this sense, this blueprint depends on bexar-network-service blueprint.
We are planning 2 phase step development.
- Step 1) Implement live migration feature using austin release code base.
- Step 2) Implement live migration feature using bexar-network-service API calls.
Thus, even if bexar-migration-live was deferred, still we can support under austin release network model(Step 1). In this sense, I think the dependency is a bit weak one. But, anyway I know that I have to follow the procedure changing specification after the Submission Deadline.

@@ Line 1: / Line 1: @@
-__NOTOC__
-* '''Launchpad Entry''': [[NovaSpec]]:bexar-migration-live
+* '''Launchpad Entry''': NovaSpec:bexar-migration-live
 * '''Created''': 2010-10-20
-* '''Contributors''': Masanori Itoh, Tushar Patil begin_of_the_skype_highlighting     end_of_the_skype_highlighting begin_of_the_skype_highlighting     end_of_the_skype_highlighting
+* '''Contributors''': Kei Masumoto, Muneyuki Noguchi, Masanori Itoh, Tushar Patil
 == Note ==
-On the 2nd Design Summit, please see: http://etherpad.openstack.org/LiveMigration
+* On the 2nd Design Summit, please see: http://etherpad.openstack.org/LiveMigration
+* Please see attached PPT presented at the Bexar Design Summit and the above etherpad note.
+* Please see notes in the Dependency section.
 == Summary ==
 Add a capability for migrating a running VM from one host to another host transparently to applications and any external entity interacting with such applications on the cloud server without taking down the cloud server and with a very negligible downtime.
-== Release Note ==
-* TBD
-== Rationale ==
-# To perform maintenance on a host server, you need to be able to migrate all of its VMs onto to another host.
-# It should be possible to live migrate any VM (e.g., n-tier e-commerce system) without requiring clients to reconnect.
-== User stories ==
-* TBD
-== Assumptions ==
-# Need more than one host in the private cloud environment.
-# Compute nodes are able to SSH to each other and should use some sort of ssh key management, otherwise host would need to supply the credentials at the time of live migration when it asks for.
-# For compatibility, it is advised to have same setup of compute nodes in the cloud environment setup.
-# In cluster environment, network interfaces of the source and target compute node typically exists on a single switched LAN.
-== Design ==
-# At present compute node copies the images locally from the image store (S3, locally) and boots the instance locally. This might slow the live migration since it has the overhead of copying the images from the source host to the target host. So consider using the shared storage like sheepdog, NFS etc. In case of shared storage there will be no need to copy the VM image from the source to the target host. In case of shared storage, the images are copied on the shared storage itself instead of copying locally onto the compute node.
-# Support both local storage and shared storage of VM images.
-# Introduce one more state of an instance to indicate specific instance is undergoing live migration. After migration is successful, change the state to running.
-# Live migration should be supported by nova-manage or Openstack API? Needs discussion. When live migration is requested, the state of the live migration is periodically monitored by the service to verify completion.
-# After live migration is initiated, then any subsequent request for that instance would be put on hold or not entertained until the migration process is complete.
-# Only one instance will be migrated at one time to start with.
-# Support live migration for KVM hypervisor to start with.
-# Volumes attached to the instance should also be accessible from the target host after live migration is successful
-# Support API to retrieve list of the compute nodes available in the private cloud setup.
-# Support API to retrieve list of the instance running on the compute node.
-== Implementation ==
- TBD
-== Dependencies ==
-. austin-migration
-. austin-extended-network-model
-. austin-openstack-api
-. austin-images-store
-. sheepdog-support (weak dependency)
-=== UI Changes ===
-* TBD
-=== Code Changes ===
-* TBD
-=== Migration ===
-* TBD
-== Test/Demo Plan ==
-# Test to check live migration works on Fedora, RHEL and Ubuntu for KVM hypervisor
-# Test to check the minimum download time of network (Ping test)
-# Test to check if the applications are running and the database connections are not dropped after live migration is successful on the target host.
-== Unresolved issues ==
-* TBD
+== Dependency ==
-== BoF agenda and discussion ==
+A Special Note:
-* TBD
+This blueprint, bexar-migration-live, depends on bexar-network-service in the following sense.
+* After we have bexar-migration-live, we can attach multiple NICs to a VM. Live Migration feature should support migrating network connectivity together with the VM. In this sense, this blueprint depends on bexar-network-service blueprint.
+* We are planning 2 phase step development.
+** Step 1) Implement live migration feature using austin release code base.
+** Step 2) Implement live migration feature using bexar-network-service API calls.
+* Thus, even if bexar-migration-live was deferred, still we can support under austin release network model(Step 1). In this sense, I think the dependency is a bit weak one. But, anyway I know that I have to follow the procedure changing specification after the Submission Deadline.
 ----
 [[Category:Spec]]