From: Mats Petersson <mats.petersson@citrix.com>
To: xen-devel@lists.xen.org
Subject: Re: How to optimize pre-copy algorithm of xen to minimize downtime?
Date: Wed, 12 Dec 2012 17:43:23 +0000 [thread overview]
Message-ID: <50C8C23B.6070003@citrix.com> (raw)
In-Reply-To: <CANq0ewsao_cmc5qd0WOPH2rnPN++ccHU2E3Sp2Tysq4Qa_c6xA@mail.gmail.com>
On 11/12/12 14:33, digvijay chauhan wrote:
>
> Hello,
> If I want to optimize the performance of precopy algorithm so
> that live migration of virtual machine using xen occurs with minimum
> downtime,then how to do it?
Having spent quite a bit of time studying the time that a domain is down
during migration in XenServer, I'm not convinced pre-copy is what is the
biggest part of downtime, assuming the Open Source product behaviour is
at least mostly doing the same things - although what the host and guest
is up to before it gets suspended/paused will have a big impact as well.
If the guest is VERY busy, you may well end up with very little memory
that doesn't need to be copied in the final copy - not sure how you can
improve this.
Have you made some measurements to show where the time is spent during
downtime.
What workloads are you looking at? What downtime numbers have you got at
present, and what portion of this is down to actually copy time, and
what is other things that need to happen during migration (e.g. bringing
the virtual HD and Net devices down, and then up again on the new guest)?
My above comments assume there is a FAST link between the old and new
host (my testing has been primarily using "localhost" migration, so the
new guest is on the same machine as the old one). For a slow link, you
may find that the copy time is more of the whole time, but again, I'm
not sure there is a huge amount that can be done without a rather large
amount of added complexity - and that may well be better put elsewhere,
e.g. compression on the network link, or some such.
I have patch for Linux 3.7rcX that improves the time Dom0 spends mapping
in the guest memory, which does have a good impact on the overall copy
time, but not that huge impact on the downtime (since the copy time is
only small part of overall downtime, at least in my testcases). Look at
list archives for Friday 7th of Dec for the latest version.
--
Mats
>
> regards,
> Digvijay
>
prev parent reply other threads:[~2012-12-12 17:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANq0ewsxV1Zb7A1N06Y_r6ogC=L39cWZeLBw-dONMWxcFhc8cw@mail.gmail.com>
2012-12-11 14:33 ` How to optimize pre-copy algorithm of xen to minimize downtime? digvijay chauhan
2012-12-12 17:43 ` Mats Petersson [this message]
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=50C8C23B.6070003@citrix.com \
--to=mats.petersson@citrix.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 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).