From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Lieven <pl@dlh.net>
Cc: Shu Ming <shuming@linux.vnet.ibm.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Stalls on Live Migration of VMs with a lot of memory
Date: Wed, 04 Jan 2012 12:28:26 +0100 [thread overview]
Message-ID: <4F0437DA.8080600@redhat.com> (raw)
In-Reply-To: <4F043689.2000604@dlh.net>
On 01/04/2012 12:22 PM, Peter Lieven wrote:
>> There were patches to move RAM migration to a separate thread. The
>> problem is that they broke block migration.
>>
>> However, asynchronous NBD is in and streaming will follow suit soon.
>> As soon as we have those two features, we might as well remove the
>> block migration code.
>
> ok, so its a matter of time, right?
Well, there are other solutions of varying complexity in the works, that
might remove the need for the migration thread or at least reduce the
problem (post-copy migration, XBRLE, vectorized hot loops). But yes, we
are aware of the problem and we should solve it in one way or the other.
> would it make sense to patch ram_save_block to always process a full ram
> block?
If I understand the proposal, then migration would hardly be live
anymore. The biggest RAM block in a 32G machine is, well, 32G big.
Other RAM blocks are for the VRAM and for some BIOS data, but they are
very small in proportion.
> - 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.
Paolo
next prev parent reply other threads:[~2012-01-04 11:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-03 18:04 [Qemu-devel] Stalls on Live Migration of VMs with a lot of memory Peter Lieven
2012-01-04 1:38 ` Shu Ming
2012-01-04 9:11 ` Peter Lieven
2012-01-04 10:53 ` Peter Lieven
2012-01-04 11:05 ` Paolo Bonzini
2012-01-04 11:22 ` Peter Lieven
2012-01-04 11:28 ` Paolo Bonzini [this message]
2012-01-04 11:42 ` Peter Lieven
2012-01-04 12:28 ` Paolo Bonzini
2012-01-04 13:08 ` Peter Lieven
2012-01-04 14:14 ` Paolo Bonzini
2012-01-04 14:17 ` Peter Lieven
2012-01-04 14:21 ` Peter Lieven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F0437DA.8080600@redhat.com \
--to=pbonzini@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pl@dlh.net \
--cc=qemu-devel@nongnu.org \
--cc=shuming@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).