Open Stack

On 07/09/2012 10:09 AM, John Garbutt wrote:
>>> - historically XenAPI had migrate, Libvirt had live migrate
>>> - But by end of Folsom we should have both having both
>>
>> Yes, but what is the difference between the two?
> Got you. I think this is right:
> 
> Migration:
> - shutdown the VM
> - move current disk to the destination
> - start VM
> - user sees reboot, and sees downtime
> - resize is very similar, just starts as different flavour

OK, got it. I pinged Anne Gentle about the docs missing this (apparently
core) API server action and she will be working to get this added to the
current docs -- especially since novaclient already has support for it...

> Live-migration:
> - snapshot running state
> - copy memory + CPU state to other machine
> - start
> - user sees VM pause for a small amount of time
> - assumes VM is on shared storage, so disks are not moved
> 
> Block-migration and live-migration:
> - as above, but disk needs to be copied

The more I think about it, I believe a single migration API would be
simplest, with the ability to specify options for the migration.
Something like:

POST /servers/<SERVER_ID>/action

{
 'action': 'migrate',
 'migrate_options':
 {
  'live': true,
  'no_live_fallback': true,
  'migrate_disks':
  {
   <DISK_UUID1>, ...
  }
 }
}

With the options being fairly self-explanatory other than the
'no_live_fallback': true being used to indicate the caller wishes to
fallback on a stop/move/start migration if shared disk (or a hypervisor
restriction or non-matching CPU restriction) prohibits the "live" migration.

Thoughts?
-jay