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
--
Mailing list: https://launchpad.net/~openstack-qa-team
Post to : openstack-qa-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-qa-team
More help : https://help.launchpad.net/ListHelp
