From: Li Zhijian <lizhijian@cn.fujitsu.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Changlong Xie <xiecl.fnst@cn.fujitsu.com>,
zhanghailiang <zhang.zhanghailiang@huawei.com>,
qemu block <qemu-block@nongnu.org>,
qemu devel <qemu-devel@nongnu.org>, Luis Tomas <luis@cs.umu.se>,
Simon Kollberg <dv11skg@cs.umu.se>, Abel Souza <abel@cs.umu.se>
Subject: Re: [Qemu-devel] COLO: how to flip a secondary to a primary?
Date: Tue, 26 Jan 2016 09:16:14 +0800 [thread overview]
Message-ID: <56A6C8DE.8020606@cn.fujitsu.com> (raw)
In-Reply-To: <20160125202001.GL2464@work-vm>
On 01/26/2016 04:20 AM, Dr. David Alan Gilbert wrote:
> * Li Zhijian (lizhijian@cn.fujitsu.com) wrote:
>>
>>
>> On 01/25/2016 09:32 AM, Wen Congyang wrote:
>>>>> f) I've not thought about the colo-proxy that much yet - I guess that
>>>>> existing connections need to keep their sequence number offset but
>>
>> Strictly speaking, after failover, we only need to keep servicing for the tcp connections which are
>> established after the last checkpoint but not all existing connections. Because after a checkpoint
>> (primary and secondary node works well), primary vm and secondary vm is same, that means the existing
>> tcp connection has the same sequence。
>>
>>>>> new connections made by what is now the primary dont need to do anything
>>>>> special.
>> Yes, you are right.
>
> I wonder whether we need to do something special to the new-secondary;
> consider this:
>
> 1 primary (P1) & secondary (S1) run together
> 2 New connection opened
> 3 secondary records an offset
> 4 <running OK for a while - no checkpoint>
> 5 primary (P1) fails; do failover to secondary
> 6 secondary (S1) still rewrites sequence for connection opened at (2)
> 7 Start new-secondary (S2), send checkpoint from S1->S2
> 8 S2 has same guest contents as S1; so the
> sequence numbers are still offset compared to the outside world.
>
> So S2 needs to be sent the offsets for existing connections, otherwise
> is S1 was then to fail, S2 would send the wrong output on the existing
> connection?
Thanks for the example.
Sure, if we support continuous FT, colo proxy need to implement migration_save and migration_load.
At the beginning of (7), we need to save colo_proxy info(including connection info and sequence offset) at S1
and load colo_proxy at S2. S1/S2 need to keep doing tcp re-writer for the connections opened at (2)
until they are closed.
Thanks
Li Zhijian
>
> Dave
>
>>
>>
>>> Hailiang or Zhijian can answer this question.
>>
>>
>> Thanks
>> Li Zhijian
>>
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
>
> .
>
--
Best regards.
Li Zhijian (8555)
next prev parent reply other threads:[~2016-01-26 1:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-22 19:35 [Qemu-devel] COLO: how to flip a secondary to a primary? Dr. David Alan Gilbert
2016-01-25 1:32 ` Wen Congyang
2016-01-25 2:11 ` Li Zhijian
2016-01-25 20:20 ` Dr. David Alan Gilbert
2016-01-26 1:16 ` Li Zhijian [this message]
2016-01-25 18:59 ` Dr. David Alan Gilbert
2016-01-26 1:06 ` 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=56A6C8DE.8020606@cn.fujitsu.com \
--to=lizhijian@cn.fujitsu.com \
--cc=abel@cs.umu.se \
--cc=dgilbert@redhat.com \
--cc=dv11skg@cs.umu.se \
--cc=luis@cs.umu.se \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=xiecl.fnst@cn.fujitsu.com \
--cc=zhang.zhanghailiang@huawei.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 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.