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 <zhangchen.f...@cn.fujitsu.com> >>>>>>> >>>>>>> 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 > >>> 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 >> >> >> . >> >