All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: reliable live migration of large and busy guests
Date: Wed, 7 Nov 2012 13:44:54 +0000	[thread overview]
Message-ID: <509A65D6.6050505@citrix.com> (raw)
In-Reply-To: <721bf725-662f-41cb-a1a3-7c908e05c188@default>

On 06/11/12 23:41, Dan Magenheimer wrote:
>> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
>> Sent: Tuesday, November 06, 2012 4:19 PM
>> To: xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] reliable live migration of large and busy guests
>>
>> As potential food for thought:
>>
>> Is there wisdom in having a new kind of live migrate which, when pausing
>> the VM on the source host, resumes the VM on the destination host.  Xen
>> would have to track not-yet-sent pages and pause the guest on pagefault,
>> and request the required page as a matter of priority.
>>
>> The advantages of this approach would be that a timing sensitive
>> workloads would be paused for far less time.  Even if it was frequently
>> being paused for pagefaults, the time to get a single page over the LAN
>> would be far quicker than the entire dirty set, at which point on
>> resume, the interrupt paths would fire again; The timing paths would
>> quickly become fully populated.  Further to that, a busy workload in the
>> guest dirtying a page which has already been sent will not result in any
>> further network traffic.
> Something like this?
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.184.2368 

Oh wow - something quite like that.  Thankyou very much.  I will read
the paper in full when I get a free moment, but the abstract looks very
interesting.

>From an idealistic point of view, it might be quite nice to have several
live migrate mechanisms, so the user can choose whether they value
minimum downtime, minimum network utilisation, or maximum safety.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com

  reply	other threads:[~2012-11-07 13:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-06 20:28 reliable live migration of large and busy guests Olaf Hering
2012-11-06 20:45 ` Keir Fraser
2012-11-06 22:18   ` Olaf Hering
2012-11-06 23:18     ` Andrew Cooper
2012-11-06 23:41       ` Dan Magenheimer
2012-11-07 13:44         ` Andrew Cooper [this message]
2012-11-07 15:10           ` Dan Magenheimer
2012-11-08 10:58             ` George Dunlap
2012-11-12 17:12               ` Dan Magenheimer
2012-11-07 14:13       ` Olaf Hering

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=509A65D6.6050505@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=xen-devel@lists.xen.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.