From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL3sy-0000Cz-T9 for qemu-devel@nongnu.org; Mon, 18 Jan 2016 02:05:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aL3sv-0005Ye-Lz for qemu-devel@nongnu.org; Mon, 18 Jan 2016 02:05:56 -0500 Received: from [59.151.112.132] (port=60162 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aL3su-0005Xb-M2 for qemu-devel@nongnu.org; Mon, 18 Jan 2016 02:05:53 -0500 References: <1450780978-19123-1-git-send-email-zhangchen.fnst@cn.fujitsu.com> <568494B8.4080105@redhat.com> <5684E9EB.3070002@cn.fujitsu.com> <568A0527.9040001@redhat.com> <568A2A5F.3090608@cn.fujitsu.com> <568A3F80.8000806@redhat.com> <568A54C2.8050300@cn.fujitsu.com> <568CA327.4020103@redhat.com> From: Zhang Chen Message-ID: <569C8EB7.3060507@cn.fujitsu.com> Date: Mon, 18 Jan 2016 15:05:27 +0800 MIME-Version: 1.0 In-Reply-To: <568CA327.4020103@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 00/10] Add colo-proxy based on netfilter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang , qemu devel Cc: zhanghailiang , Li Zhijian , Gui jianfeng , "eddie.dong" , "Dr. David Alan Gilbert" , Huang peng , Gong lei , Stefan Hajnoczi , jan.kiszka@siemens.com, Yang Hongyang On 01/06/2016 01:16 PM, Jason Wang wrote: > > On 01/04/2016 07:17 PM, Zhang Chen wrote: >> >> On 01/04/2016 05:46 PM, Jason Wang wrote: >>> On 01/04/2016 04:16 PM, Zhang Chen wrote: >>>> On 01/04/2016 01:37 PM, Jason Wang wrote: >>>>> On 12/31/2015 04:40 PM, Zhang Chen wrote: >>>>>> On 12/31/2015 10:36 AM, Jason Wang wrote: >>>>>>> On 12/22/2015 06:42 PM, Zhang Chen wrote: >>>>>>>> From: zhangchen >>>>>>>> >>>>>>>> Hi,all >>>>>>>> >>>>>>>> This patch add an colo-proxy object, COLO-Proxy is a part of COLO, >>>>>>>> based on qemu netfilter and it's a plugin for qemu netfilter. the >>>>>>>> function >>>>>>>> keep Secondary VM connect normal to Primary VM and compare packets >>>>>>>> sent by PVM to sent by SVM.if the packet difference,notify COLO do >>>>>>>> checkpoint and send all primary packet has queued. >>>>>>> Thanks for the work. I don't object this method but still not >>>>>>> convinced >>>>>>> that qemu is the best place for this. >>>>>>> >>>>>>> As been raised in the past discussion, it's almost impossible to >>>>>>> cooperate with vhost backends. If we want this to be used in >>>>>>> production >>>>>>> environment, need to think of a solution for vhost. There's no such >>>>>>> worry if we decouple this from qemu. >>>>>>> >>>>>>>> You can also get the series from: >>>>>>>> >>>>>>>> https://github.com/zhangckid/qemu/tree/colo-v2.2-periodic-mode-with-colo-proxyV2 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Usage: >>>>>>>> >>>>>>>> primary: >>>>>>>> -netdev tap,id=bn0 -device e1000,netdev=bn0 >>>>>>>> -object >>>>>>>> colo-proxy,id=f0,netdev=bn0,queue=all,mode=primary,addr=host:port >>>>>>>> >>>>>>>> secondary: >>>>>>>> -netdev tap,id=bn0 -device e1000,netdev=bn0 >>>>>>>> -object >>>>>>>> colo-proxy,id=f0,netdev=bn0,queue=all,mode=secondary,addr=host:port >>>>>>> Have a quick glance at how secondary mode work. What it does is just >>>>>>> forwarding packets between a nic and a socket, qemu socket >>>>>>> backend did >>>>>>> exact the same job. You could even use socket in primary node and >>>>>>> let >>>>>>> packet compare module talk to both primary and secondary node. >>>>>> If we use qemu socket backend , the same netdev will used by qemu >>>>>> socket and >>>>>> qemu netfilter. this will against qemu net design. and then, when >>>>>> colo >>>>>> do failover, >>>>>> secondary do not have backend to use. that's the real problem. >>>>> Then, maybe it's time to implement changing the netdev of a nic. The >>>>> point here is that what secondary mode did is in fact a netdev backend >>>>> instead of a filter ... >>>> Currently, you are right. in colo-proxy V2 code, I just compare IP >>>> packet to >>>> decide whether to do checkpoint. >>>> But, in colo-proxy V3 I will compare tcp,icmp,udp packet to decide it. >>>> because that can reduce frequency of checkpoint and improve >>>> performance. To keep tcp connection well, colo secondary need to record >>>> primary guest's init seq and adjust secondary guest's ack. if colo do >>>> failover, >>>> secondary also need do this to old tcp connection. qemu socket >>>> can't do this job. >>> So a question here: is it a must to do things (e.g TCP analysis stuffs) >>> at secondary? Looks like we could do this at primary node. And I saw >>> you're doing packet comparing in primary node, any advantages of doing >>> this in primary instead of secondary? >> We think must to do this in secondary, because if colo do >> failover,secondary >> must continues do TCP analysis stuffs to before tcp connection(if not, >> tcp connection >> will disconnect in that time), in this time primary already down or >> disconnect to >> secondary.so we can't make primary do this TCP analysis stuffs.it can >> not ensure >> FT function. >> >> Thanks >> zhangchen > Makes sense. > > Thanks Hi~, Jason. No news for a week. Can you give me some comments for code. Let's make colo-proxy work well. Thanks zhangchen >>>> and another problem is do failover, if we use qemu socket >>>> to be backend in secondary, when colo do failover, I don't know how to >>>> change >>>> secondary be a normal qemu, if you know, please tell me. >>> Current qemu couldn't do this, but I mean we implement something like >>> nic_change_backend which can change nic's peer(s). With this, in >>> secondary, we can replace the socket backend with whatever you want (e.g >>> tap or other). >>> >>> Thanks >>> >>>> Thanks for your revew >>>> zhangchen >>> >>> . >>> > > > . > -- Thanks zhangchen