From: Wen Congyang <wency@cn.fujitsu.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] stop the iteration when too many pages is transferred
Date: Mon, 22 Nov 2010 10:25:37 +0800 [thread overview]
Message-ID: <4CE9D4A1.6050900@cn.fujitsu.com> (raw)
In-Reply-To: <4CE7313B.1070103@codemonkey.ws>
At 2010年11月20日 10:23, Anthony Liguori Write:
> On 11/17/2010 08:32 PM, Wen Congyang wrote:
>> When the total sent page size is larger than max_factor
>> times of the size of guest OS's memory, stop the
>> iteration.
>> The default value of max_factor is 3.
>>
>> This is similar to XEN.
>>
>>
>> Signed-off-by: Wen Congyang
>>
>
> I'm strongly opposed to doing this. I think Xen gets this totally wrong.
>
> Migration is a contract. When you set the stop time, you're saying that
> you want only want the guest to experience a fixed amount of downtime.
> Stopping the guest after some arbitrary number of iterations makes the
> downtime non-deterministic. With a very large guest, this could wreak
> havoc causing dropped networking connections, etc.
>
Thanks for your comment.
As a developer, I know the downtime.
But as a user, he does not know the downtime.
When he migrates a very large guest lively without setting the stop time,
he does not say "I want the guest to experience a fixed amount of downtime",
he only wants to migrate the guest in a short time, the migration should
be done during some minutes, not ever for ever.
If we set the stop time too larger, this could also wreak havoc causing
dropped networking connections, etc.
I think we can do it as the following:
1. If the user does not set the stop time, we should complete the
migration in a short time.
2. If the user sets the stop time, we do it as now.
> It's totally unsafe.
>
> If a management tool wants this behavior, they can set a timeout and
> explicitly stop the guest during the live migration. IMHO, such a
> management tool is not doing it's job properly but it still can be
> implemented.
>
> Regards,
>
> Anthony Liguori
>
next prev parent reply other threads:[~2010-11-22 2:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 2:32 [Qemu-devel] [PATCH] stop the iteration when too many pages is transferred Wen Congyang
2010-11-20 2:23 ` Anthony Liguori
2010-11-22 2:25 ` Wen Congyang [this message]
2010-11-22 7:11 ` KAMEZAWA Hiroyuki
2010-11-24 9:23 ` [Qemu-devel] " Michael S. Tsirkin
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=4CE9D4A1.6050900@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.