From: Anthony Liguori <anthony@codemonkey.ws>
To: Cleber Rosa <crosa@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] postcopy livemigration proposal
Date: Mon, 08 Aug 2011 10:52:04 -0500 [thread overview]
Message-ID: <4E400624.1060504@codemonkey.ws> (raw)
In-Reply-To: <4E401449.7050404@redhat.com>
On 08/08/2011 11:52 AM, Cleber Rosa wrote:
> On 08/08/2011 07:47 AM, Dor Laor wrote:
>> On 08/08/2011 01:59 PM, Nadav Har'El wrote:
>>>>> * What's is postcopy livemigration
>>>>> It is is yet another live migration mechanism for Qemu/KVM, which
>>>>> implements the migration technique known as "postcopy" or "lazy"
>>>>> migration. Just after the "migrate" command is invoked, the execution
>>>>> host of a VM is instantaneously switched to a destination host.
>>>
>>> Sounds like a cool idea.
>>>
>>>>> The benefit is, total migration time is shorter because it transfer
>>>>> a page only once. On the other hand precopy may repeat sending same
>>>>> pages
>>>>> again and again because they can be dirtied.
>>>>> The switching time from the source to the destination is several
>>>>> hunderds mili seconds so that it enables quick load balancing.
>>>>> For details, please refer to the papers.
>>>
>>> While these are the obvious benefits, the possible downside (that, as
>>> always, depends on the workload) is the amount of time that the guest
>>> workload runs more slowly than usual, waiting for pages it needs to
>>> continue. There are a whole spectrum between the guest pausing
>>> completely
>>> (which would solve all the problems of migration, but is often
>>> considered
>>> unacceptible) and running at full-speed. Is it acceptable that the guest
>>> runs at 90% speed during the migration? 50%? 10%?
>>> I guess we could have nothing to lose from having both options, and
>>> choosing
>>> the most appropriate technique for each guest!
>
> Not sure if it's possible to have smart heuristics on guest memory page
> faults, but maybe a technique that reads ahead more pages if a given
> pattern is detected may help to lower the impact.
It's got to be a user choice. Post-copy can mean unbounded downtime for
a guest with no way to mitigate it. It's impossible to cancel a
post-copy migration.
I actually think the use-cases for post-copy are fairly limited in an
enterprise environment.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2011-08-08 15:52 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-08 3:24 [RFC] postcopy livemigration proposal Isaku Yamahata
2011-08-08 3:24 ` [Qemu-devel] " Isaku Yamahata
2011-08-08 9:20 ` Dor Laor
2011-08-08 9:20 ` [Qemu-devel] " Dor Laor
2011-08-08 9:40 ` Yaniv Kaul
2011-08-08 9:40 ` [Qemu-devel] " Yaniv Kaul
2011-08-08 21:42 ` Anthony Liguori
2011-08-08 21:42 ` Anthony Liguori
2011-08-08 10:59 ` Nadav Har'El
2011-08-08 10:59 ` [Qemu-devel] " Nadav Har'El
2011-08-08 11:47 ` Dor Laor
2011-08-08 11:47 ` [Qemu-devel] " Dor Laor
2011-08-08 16:52 ` Cleber Rosa
2011-08-08 15:52 ` Anthony Liguori [this message]
2011-08-08 12:32 ` Anthony Liguori
2011-08-08 12:32 ` [Qemu-devel] " Anthony Liguori
2011-08-08 15:11 ` Dor Laor
2011-08-08 15:11 ` Dor Laor
2011-08-08 15:29 ` Anthony Liguori
2011-08-08 15:29 ` Anthony Liguori
2011-08-08 15:36 ` Avi Kivity
2011-08-08 15:36 ` [Qemu-devel] " Avi Kivity
2011-08-08 15:59 ` Anthony Liguori
2011-08-08 15:59 ` Anthony Liguori
2011-08-08 19:47 ` Dor Laor
2011-08-08 19:47 ` [Qemu-devel] " Dor Laor
2011-08-09 2:07 ` Isaku Yamahata
2011-08-09 2:07 ` Isaku Yamahata
2011-08-08 9:38 ` Stefan Hajnoczi
2011-08-08 9:38 ` Stefan Hajnoczi
2011-08-08 9:43 ` Isaku Yamahata
2011-08-08 9:43 ` Isaku Yamahata
2011-08-08 12:38 ` Avi Kivity
2011-08-08 12:38 ` [Qemu-devel] " Avi Kivity
2011-08-09 2:33 ` Isaku Yamahata
2011-08-09 2:33 ` [Qemu-devel] " Isaku Yamahata
2011-08-10 13:55 ` Avi Kivity
2011-08-10 13:55 ` [Qemu-devel] " Avi Kivity
2011-08-11 2:19 ` Isaku Yamahata
2011-08-11 2:19 ` [Qemu-devel] " Isaku Yamahata
2011-08-11 16:55 ` Andrea Arcangeli
2011-08-11 16:55 ` [Qemu-devel] " Andrea Arcangeli
2011-08-12 11:07 ` [PATCH][RFC] post copy chardevice (was Re: [RFC] postcopy livemigration proposal) Isaku Yamahata
2011-08-12 11:07 ` [Qemu-devel] " Isaku Yamahata
2011-08-12 11:09 ` Isaku Yamahata
2011-08-12 11:09 ` [Qemu-devel] " Isaku Yamahata
2011-08-12 21:26 ` Blue Swirl
2011-08-12 21:26 ` Blue Swirl
2011-08-15 19:29 ` Avi Kivity
2011-08-15 19:29 ` [Qemu-devel] " Avi Kivity
2011-08-16 1:42 ` Isaku Yamahata
2011-08-16 1:42 ` [Qemu-devel] " Isaku Yamahata
2011-08-16 13:40 ` Avi Kivity
2011-08-16 13:40 ` [Qemu-devel] " Avi Kivity
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=4E400624.1060504@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=crosa@redhat.com \
--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.