From: Oliver Hookins <oliver.hookins@nokia.com>
To: ext Juan Quintela <quintela@redhat.com>
Cc: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>,
qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Memory sync algorithm during migration
Date: Mon, 21 Nov 2011 17:32:44 +0100 [thread overview]
Message-ID: <20111121163244.GA17441@spacemoose.devbln.europe.nokia.com> (raw)
In-Reply-To: <87pqgtmzkx.fsf@trasno.mitica>
On Tue, Nov 15, 2011 at 11:47:58AM +0100, ext Juan Quintela wrote:
> Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp> wrote:
> > Adding qemu-devel ML to CC.
> >
> > Your question should have been sent to qemu-devel ML because the logic
> > is implemented in QEMU, not KVM.
> >
> > (2011/11/11 1:35), Oliver Hookins wrote:
> >> Hi,
> >>
> >> I am performing some benchmarks on KVM migration on two different types of VM.
> >> One has 4GB RAM and the other 32GB. More or less idle, the 4GB VM takes about 20
> >> seconds to migrate on our hardware while the 32GB VM takes about a minute.
> >>
> >> With a reasonable amount of memory activity going on (in the hundreds of MB per
> >> second) the 32GB VM takes 3.5 minutes to migrate, but the 4GB VM never
> >> completes. Intuitively this tells me there is some watermarking of dirty pages
> >> going on that is not particularly efficient when the dirty pages ratio is high
> >> compared to total memory, but I may be completely incorrect.
>
> > You can change the ratio IIRC.
> > Hopefully, someone who knows well about QEMU will tell you better ways.
> >
> > Takuya
> >
> >>
> >> Could anybody fill me in on what might be going on here? We're using libvirt
> >> 0.8.2 and kvm-83-224.el5.centos.1
>
> This is pretty old qemu/kvm code base.
> In principle, it makes no sense that with 32GB RAM migration finishes,
> and with 4GB RAM it is unable (intuitively it should be, if ever, the
> other way around).
>
> Do you have an easy test that makes the problem easily reproducible?
> Have you tried ustream qemu.git? (some improvements on that department).
I've just tried the qemu-kvm 0.14.1 tag which seems to be the latest that builds
on my platform. For some strange reason migrations always seem to fail in one
direction with "Unknown savevm section or instance 'hpet' 0" messages.
This seems to point to different migration protocols on either end but they are
both running the same version of qemu-kvm I built. Does this ring any bells for
anyone?
next prev parent reply other threads:[~2011-11-21 16:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20111110163532.GE5656@spacemoose.devbln.europe.nokia.com>
2011-11-15 9:21 ` [Qemu-devel] Memory sync algorithm during migration Takuya Yoshikawa
2011-11-15 10:47 ` Juan Quintela
2011-11-15 10:55 ` Oliver Hookins
2011-11-18 11:53 ` Oliver Hookins
2011-11-21 16:32 ` Oliver Hookins [this message]
2011-11-22 9:31 ` Juan Quintela
2011-11-22 13:04 ` Oliver Hookins
2011-11-22 16:05 ` Pierre Riteau
2011-11-22 17:53 ` oliver.hookins
2011-11-22 16:44 ` Pierre Riteau
2011-11-23 10:40 ` Oliver Hookins
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=20111121163244.GA17441@spacemoose.devbln.europe.nokia.com \
--to=oliver.hookins@nokia.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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).