From: Ian Campbell <ian.campbell@citrix.com>
To: Wen Congyang <wency@cn.fujitsu.com>,
xen devel <xen-devel@lists.xen.org>,
Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Shriram Rajagopalan <rshriram@cs.ubc.ca>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Changlong Xie <xiecl.fnst@cn.fujitsu.com>,
Wei Liu <wei.liu2@citrix.com>,
Yang Hongyang <hongyang.yang@easystack.cn>
Subject: Re: [PATCH v4 1/5] remus: don't call stream_continue() when doing failover
Date: Mon, 18 Jan 2016 16:45:44 +0000 [thread overview]
Message-ID: <1453135544.6020.188.camel@citrix.com> (raw)
In-Reply-To: <1453095622-14859-2-git-send-email-wency@cn.fujitsu.com>
On Mon, 2016-01-18 at 13:40 +0800, Wen Congyang wrote:
> stream_continue() is used for migration to read emulator
> xenstore data and emulator context. For remus, if we do
> failover, we have read it in the checkpoint cycle, and
> we only need to complete the stream.
>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> tools/libxl/libxl_stream_read.c | 35 ++++++++++++++++++++++++++++++-----
> 1 file changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxl/libxl_stream_read.c
> b/tools/libxl/libxl_stream_read.c
> index 258dec4..24305f4 100644
> --- a/tools/libxl/libxl_stream_read.c
> +++ b/tools/libxl/libxl_stream_read.c
> @@ -101,6 +101,19 @@
> * - stream_write_emulator_done()
> * - stream_continue()
> *
> + * 4) Failover for remus
I don't think this is really #4 in the list which precedes it. I think a
section "Failover for remus" would be absolutely fine right that the end of
this comment block though, i.e. right after the "Depending on the
contents..." paragraph.
Andy?
> + * - we buffer all records until a CHECKPOINT_END record is received
> + * - we will use the records when a CHECKPOINT_END record is received
"we will consume the buffered records..."
> + * - if we find some internal error, the rc or retval is not 0 in
s/the/then/
> + * libxl__xc_domain_restore_done(). In this case, we don't resume the
> + * guest
> + * - if we need to do failover from primary, the rc and retval are 0
s/the/then/ again and I would say "are both 0" for clarity (assuming that
is indeed the requirement).
> + * in libxl__xc_domain_restore_done(). In this case, the buffered state
> + * will be dropped, because we don't receive a CHECKPOINT_END record,
haven't received
> + * and it is a inconsistent state. In libxl__xc_domain_restore_done(),
"an inconsistent".
I think I would say "... and therefore the buffered state is inconsistent".
- stream_continue(egc, stream);
> + if (checkpointed_stream) {
> + /*
> + * Failover from primary. Domain state is currently at a
> + * consistent checkpoint, complete the stream, and call
> + * stream->completion_callback() to resume the guest.
> + */
> + stream_complete(egc, stream, 0);
Is it possible to get here having never received a single CHECKPOINT_END?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-01-18 16:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 5:40 [PATCH v4 0/5] migration/remus: bug fix and cleanup Wen Congyang
2016-01-18 5:40 ` [PATCH v4 1/5] remus: don't call stream_continue() when doing failover Wen Congyang
2016-01-18 16:45 ` Ian Campbell [this message]
2016-01-19 1:05 ` Wen Congyang
2016-01-18 5:40 ` [PATCH v4 2/5] remus: resume immediately if libxl__xc_domain_save_done() completes Wen Congyang
2016-01-18 16:51 ` Ian Campbell
2016-01-19 1:01 ` Wen Congyang
2016-01-19 11:01 ` Ian Campbell
2016-01-18 5:40 ` [PATCH v4 3/5] tools/libxc: don't send end record if remus fails Wen Congyang
2016-01-18 16:53 ` Ian Campbell
2016-01-18 16:53 ` Ian Campbell
2016-01-18 5:40 ` [PATCH v4 4/5] tools/libxc: error handling for the postcopy() callback Wen Congyang
2016-01-18 16:53 ` Ian Campbell
2016-01-18 5:40 ` [PATCH v4 5/5] tools/libxl: remove unused function libxl__domain_save_device_model() Wen Congyang
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=1453135544.6020.188.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=hongyang.yang@easystack.cn \
--cc=ian.jackson@eu.citrix.com \
--cc=rshriram@cs.ubc.ca \
--cc=wei.liu2@citrix.com \
--cc=wency@cn.fujitsu.com \
--cc=xen-devel@lists.xen.org \
--cc=xiecl.fnst@cn.fujitsu.com \
/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).