On 21 Apr 2016, at 14:01, Ollie Armstrong <ollie(a)fubra.com>
wrote:
On 21 April 2016 at 12:43, Michal Skrivanek <michal.skrivanek(a)redhat.com> wrote:
>> max_outgoing_migrations = 3
>
> you should lower this, otherwise it won’t fit (1 migration at 100MBps would eat your
whole link already). So use 1
>
>> migration_downtime = 1000
>
> it’s not really 1000. There’s a UI for that in Edit VM, so you shouldn’t set it here
at all
> and if you do, the algorithm behind it is not-so-great in <=3.6.5.
> Use migration_downtime_steps=3 or 5 or something lower to mitigate that wrong
algorithm behavior
>
> if you need to overcome a longer peak period of activity, also change
migration_progress_timeout to something more than 150s
Thanks so much for the tips Michal, I really appreciate it. I'll have
to try these tweaks in my next maintenance window, so I'll post my
findings in a few days.
Hi,
great. i’d like to hear back
i don’t know your workload or constraints, but if you don’t know what to try then i would
do
migration_max_bandwidth=100
max_outgoing_migrations=1
migration_downtime=5000 (if you don’t mind at most 5s delay the VM may experience during
the handover)
migration_downtime_steps=3
migration_progress_timeout=600
and please gather the log the same way as before so i can see how is it progressing over
time, it’s helpful to understand why it doesn’t converge
4.0 will provide better logging capabilities, for now it’s not so great…but at least
something
Thanks,
michal
Cheers,
Ollie