From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG39E-0006Dd-GN for qemu-devel@nongnu.org; Mon, 04 Jan 2016 06:18:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG39B-00041H-6e for qemu-devel@nongnu.org; Mon, 04 Jan 2016 06:18:00 -0500 Received: from [59.151.112.132] (port=27313 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG39A-00040M-7o for qemu-devel@nongnu.org; Mon, 04 Jan 2016 06:17:57 -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> From: Zhang Chen Message-ID: <568A54C2.8050300@cn.fujitsu.com> Date: Mon, 4 Jan 2016 19:17:22 +0800 MIME-Version: 1.0 In-Reply-To: <568A3F80.8000806@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 , 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 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 >> 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