On 12/31/2015 04:02 PM, Li Zhijian 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. > > Yes, I agree with you. But not everything is perfect at the beginning. > If we implement proxy as kernel modules, maybe some one will ask how > about the packet(e.g. vhost-user) that host kernel can not touch.
Then I think the best place is still in userspace but not qemu. With this the packet comparing module can easily accept the mirrored traffic from both kernel and userspace. And qemu part can focus on the infrastructures to support them (e.g mirroring traffic to a socket or elsewhere). > > As you said, colo-proxy in qemu will not support vhost scene, but it > can make > colo more easier to be used so that more and more pepole will join us > to test it. > I'm looking forward to that day. Agree, so moving this out of qemu can greatly reduce the complexity and make it easier to be merged. > > if everything goes fine, I think colo can support vhost scene in other > way(such as > introduce extra proxy module in kernel) in the feature. I believe we don't want duplicate codes & bugs(fixes) in two places. > > So, I think colo-proxy in qemu is a good choice for current COLO. > > Thanks > Li
