Hi Vish, On 10 August 2012 00:27, Vishvananda Ishaya <[email protected]> wrote: > > On Aug 9, 2012, at 7:13 AM, "Daniel P. Berrange" <[email protected]> wrote: > >> >> With non-live migration, the migration operation is guaranteed to >> complete. With live migration, you can get into a non-convergence >> scenario where the guest is dirtying data faster than it can be >> migrated. With the way Nova currently works the live migration >> will just run forever with no way to stop it. So if you want to >> enable live migration by default, we'll need todo more than >> simply set the flag. Nova will need to be able to monitor the >> migration, and either cancel it after some time, or tune the >> max allowed downtime to let it complete > > Ah good to know. So it sounds like we should keep the default as-is > for now and revisit it later.
I'm not so sure. It seems to me that "nova migrate" should be the offline/paused migration and "nova live-migration" should be _live_ migration, like it says. Semantic mismatches like this exposed to operators/users are bad news. As it is, I don't even know what "nova migrate" is supposed to do...? There's at least a need to improve the docs on this. Daniel's point about the non-convergence cases with [live|block]-migration is certainly good to know. It sounds like in practice the key settings, such as the allowable live-migration downtime, should be tuned to the deployment. Nova should probably default to a conservatively high allowable downtime. Daniel; any advice about choosing a sensible value for the allowable downtime? -- Cheers, ~Blairo _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
