Re: [Qemu-devel] Stalls on Live Migration of VMs with a lot of memory

[Paolo Bonzini <pbonzini@redhat.com>]

On 01/04/2012 12:42 PM, Peter Lieven wrote:
>>
> ok, then i misunderstood the ram blocks thing. i thought the guest ram
> would consist of a collection of ram blocks.
> then let me describe it differntly. would it make sense to process
> bigger portions of memory (e.g. 1M) in stage 2 to reduce the number of
> calls to cpu_physical_memory_reset_dirty and instead run it on bigger
> portions of memory. we might loose a few dirty pages but they will be
> tracked in the next iteration in stage 2 or in stage 3 at least. what
> would be necessary is that nobody marks a page dirty
> while i copy the dirty information for the portion of memory i want to
> process.

Dirty memory tracking is done by the hypervisor and must be done at page 
granularity.

>>> - in stage 3 the vm is stopped, right? so there can't be any more dirty
>>> blocks after scanning the whole memory once?
>>
>> No, stage 3 is entered when there are very few dirty memory pages
>> remaining.  This may happen after scanning the whole memory many
>> times.  It may even never happen if migration does not converge
>> because of low bandwidth or too strict downtime requirements.
>>
> ok, is there a chance that i lose one final page if it is modified just
> after i walked over it and i found no other page dirty (so bytes_sent = 0).

No, of course not.  Stage 3 will send all missing pages while the VM is 
stopped.  There is a chance that the guest will go crazy and start 
touching lots of pages at exactly the wrong time, and thus the downtime 
will be longer than expected.  However, that's a necessary evil; if you 
cannot accept that, post-copy migration would provide a completely 
different set of tradeoffs.

(BTW, bytes_sent = 0 is very rare).

Paolo