Difference between revisions of "LiveMigration"

Revision as of 16:03, 10 November 2010

• 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

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

1. To perform maintenance on a host server, you need to be able to migrate all of its VMs onto to another host.
2. 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

1. Need more than one host in the private cloud environment.
2. 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.
3. For compatibility, it is advised to have same setup of compute nodes in the cloud environment setup.
4. In cluster environment, network interfaces of the source and target compute node typically exists on a single switched LAN.

Design

1. 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.
2. Support both local storage and shared storage of VM images.
3. Introduce one more state of an instance to indicate specific instance is undergoing live migration. After migration is successful, change the state to running.
4. 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.
5. 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.
6. Only one instance will be migrated at one time to start with.
7. Support live migration for KVM hypervisor to start with.
8. Volumes attached to the instance should also be accessible from the target host after live migration is successful
9. Support API to retrieve list of the compute nodes available in the private cloud setup.
10. Support API to retrieve list of the instance running on the compute node.

Implementation

TBD

Dependencies

　1. austin-migration 　2. austin-extended-network-model 　3. austin-openstack-api 　4. austin-images-store 　5. sheepdog-support (weak dependency)

UI Changes

• TBD

Code Changes

• TBD

Migration

• TBD

Test/Demo Plan

1. Test to check live migration works on Fedora, RHEL and Ubuntu for KVM hypervisor
2. Test to check the minimum download time of network (Ping test)
3. 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

BoF agenda and discussion

• TBD