|
From: | Zhang Chen |
Subject: | Re: [Qemu-devel] [RFC PATCH v2 00/10] Add colo-proxy based on netfilter |
Date: | Mon, 18 Jan 2016 15:05:27 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 |
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 <address@hidden> 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:portHave 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 zhangchenMakes 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). ThanksThanks for your revew zhangchen..
-- Thanks zhangchen
[Prev in Thread] | Current Thread | [Next in Thread] |