From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIXye-0006xb-Nh for qemu-devel@nongnu.org; Fri, 24 Jul 2015 04:05:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZIXya-0001RR-7H for qemu-devel@nongnu.org; Fri, 24 Jul 2015 04:05:08 -0400 Received: from [59.151.112.132] (port=11717 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZIXyY-0001L3-WE for qemu-devel@nongnu.org; Fri, 24 Jul 2015 04:05:04 -0400 Message-ID: <55B1F196.2000008@cn.fujitsu.com> Date: Fri, 24 Jul 2015 16:04:38 +0800 From: Yang Hongyang MIME-Version: 1.0 References: <55AC9859.3050100@cn.fujitsu.com> <20150720103208.GA12675@stefanha-thinkpad.redhat.com> <55B19F25.10905@redhat.com> In-Reply-To: <55B19F25.10905@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [POC] colo-proxy in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Wang , "Dong, Eddie" , Stefan Hajnoczi , Li Zhijian Cc: zhanghailiang , "jan.kiszka@siemens.com" , "qemu-devel@nongnu.org" , "peter.huangpeng" , "Gonglei (Arei)" , "stefanha@redhat.com" , "dgilbert@redhat.com" Hi Jason, On 07/24/2015 10:12 AM, Jason Wang wrote: > > > On 07/24/2015 10:04 AM, Dong, Eddie wrote: >> Hi Stefan: >> Thanks for your comments! >> >>> On Mon, Jul 20, 2015 at 02:42:33PM +0800, Li Zhijian wrote: >>>> We are planning to implement colo-proxy in qemu to cache and compare >>> packets. >>> >>> I thought there is a kernel module to do that? >> Yes, that is the previous solution the COLO sub-community choose to go, but we realized it might be not the best choices, and thus we want to bring discussion back here :) More comments are welcome. >> > > Hi: > > Could you pls describe more details on this decision? What's the reason > that you realize it was not the best choice? Below is my opinion: We realized that there're disadvantages do it in kernel spaces: 1. We need to recompile kernel: the colo-proxy kernel module is implemented as a nf conntrack extension. Adding a extension need to modify the extension struct in-kernel, so recompile kernel is needed. 2. We need to recompile iptables/nftables to use together with the colo-proxy kernel module. 3. Need to configure primary host to forward input packets to secondary as well as configure secondary to forward output packets to primary host, the network topology and configuration is too complex for a regular user. You can refer to http://wiki.qemu.org/Features/COLO to see the network topology and the steps to setup an env. Setup a test env is too complex. The usability is so important to a feature like COLO which provide VM FT solution, if fewer people can/willing to setup the env, the feature is useless. So we decide to develop user space colo-proxy. The advantage is obvious, 1. we do not need to recompile kernel. 2. No need to recompile iptables/nftables. 3. we do not need to deal with the network configuration, we just using a socket connection between 2 QEMUs to forward packets. 4. A complete VM FT solution in one go, we have already developed the block replication in QEMU, so with the network replication in QEMU, all components we needed are within QEMU, this is very important, it greatly improves the usability of COLO feature! We hope it will gain more testers, users and developers. 5. QEMU will gain a complete VM FT solution and the most advantage FT solution so far! Overall, usability is the most important factor that impact our choice. > > Thanks > . > -- Thanks, Yang.