Re: [Qemu-devel] [PATCH] ram_save_live: add a no-progress convergence rule

[Anthony Liguori]

Dor Laor wrote: 
> The problem is that if migration is not progressing since the guest is 
> dirtying pages
> faster than the migration protocol can send, than we just waist time 
> and cpu.
> The minimum is to notify the monitor interface in order to let mgmt 
> daemon to trap it.
> We can easily see this issue while running iperf in the guest or any 
> other high load/dirty
> pages scenario.

The problem is, what's the metric for determining the guest isn't 
progressing?  A raw iteration count is not a valid metric.  It may be 
expected that the migration take 50 iterations.

The management tool knows the guest isn't progressing when it decides 
that a guest isn't progressing :-)

> We can also make it configurable using the monitor migrate command. 
> For example:
> migrate -d -no_progress -threshold=x tcp:....

Theshold is really a bad metric to use.  You have no idea how much data 
has been passed in each iteration.  If you only needed one more 
iteration, then stopping the migration short was a really bad idea.

The only thing that this does is give a false sense of security.  
Management tools have to deal with forcing migration convergence based 
on policies.  If a management tool isn't doing this today, it's broken IMHO.

Basically, threshold introduces a regression.  If you run iperf and 
migrate a guest with a very large memory size, after migration, you'll 
get soft lockups because the guest hasn't been running for 10 seconds.  
This is bad.

Regards,

Anthony Liguori