openstack team mailing list archive

[Blair Bethwaite <blair.bethwaite@xxxxxxxxx>]

Hi Vish,

On 10 August 2012 00:27, Vishvananda Ishaya <vishvananda@xxxxxxxxx> wrote:
>
> On Aug 9, 2012, at 7:13 AM, "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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