From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41834) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG1j7-0005UH-RI for qemu-devel@nongnu.org; Mon, 04 Jan 2016 04:46:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG1j3-0003RP-K1 for qemu-devel@nongnu.org; Mon, 04 Jan 2016 04:46:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG1j3-0003RL-Bw for qemu-devel@nongnu.org; Mon, 04 Jan 2016 04:46: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> From: Jason Wang Message-ID: <568A3F80.8000806@redhat.com> Date: Mon, 4 Jan 2016 17:46:40 +0800 MIME-Version: 1.0 In-Reply-To: <568A2A5F.3090608@cn.fujitsu.com> Content-Type: text/plain; charset=utf-8 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: Zhang Chen , qemu devel , Stefan Hajnoczi Cc: zhanghailiang , Li Zhijian , Gui jianfeng , "eddie.dong" , "Dr. David Alan Gilbert" , Huang peng , Gong lei , jan.kiszka@siemens.com, Yang Hongyang 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? > 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