From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNZe5-00067q-25 for qemu-devel@nongnu.org; Mon, 25 Jan 2016 00:24:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNZe1-0003PH-SN for qemu-devel@nongnu.org; Mon, 25 Jan 2016 00:24:56 -0500 Received: from szxga01-in.huawei.com ([58.251.152.64]:28745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNZe1-0003O9-3Z for qemu-devel@nongnu.org; Mon, 25 Jan 2016 00:24:53 -0500 References: <1453451811-11860-1-git-send-email-zhang.zhanghailiang@huawei.com> <20160122100756.GD14825@redhat.com> <56A20604.4000407@huawei.com> <20160122103858.GE14825@redhat.com> <56A58165.8070503@huawei.com> From: Hailiang Zhang Message-ID: <56A5B185.2030604@huawei.com> Date: Mon, 25 Jan 2016 13:24:21 +0800 MIME-Version: 1.0 In-Reply-To: <56A58165.8070503@huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/7] Netfilter: Add each netdev a default filter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: jasowang@redhat.com, hongyang.yang@easystack.cn, peter.huangpeng@huawei.com, zhangchen.fnst@cn.fujitsu.com, qemu-devel@nongnu.org On 2016/1/25 9:59, Hailiang Zhang wrote: > On 2016/1/22 18:38, Daniel P. Berrange wrote: >> On Fri, Jan 22, 2016 at 06:35:48PM +0800, Hailiang Zhang wrote: >>> On 2016/1/22 18:07, Daniel P. Berrange wrote: >>>> On Fri, Jan 22, 2016 at 04:36:44PM +0800, zhanghailiang wrote: >>>>> This series is a prerequisite for COLO, here we add each netdev >>>>> a default buffer filter, it is disabled by default, and has >>>>> no side effect for delivering packets in net layer. >>>> >>>> Why can't whatever is launching QEMU just setup filters explicitly >>>> if they want to use COLO ? I'm not seeing an obvious compelling >>>> reason to add this by default and then add extra code to deal >>>> with special casing its behaviour. >>>> >>> >>> The main reason is, we hope to support hot add network during VM's COLO >>> lifetime in the future. (I'm not quite sure if this usage case is really exist, >>> but we don't want the VM in COLO state has too many limitations.) >>> >>> Maybe add an option that users can control if they want to use COLO or not is more >>> acceptable ? With this option, we can decide whether to add the default filter or not. >>> Or, we could dynamically add filter while users ask to go into COLO state for VM. >>> (We have discussed this before in community, and Jason suggested me to add default >>> filter for each netdev to support hot-add network during COLO state). >>> >>> What's your suggestion ? >> >> Why can't the app hot-adding the network interface also configure a >> filter at that time if they're using COLO ? >> > > Yes, they can certainly do that, but they will need to do more works: > 1) netdev_add/device_add add NIC 2) identify if VM is in COLO state > 3) if step 2) is YES, object-add filter for the new NIC. > Er, i have forgotten something, we have to do some other works for COLO if we didn't append each netdev a default netfilter. While do failover work, we should consider to remove the extra filters or keep them if the users decide if they continue another COLO lifetime for VM. Thanks, Hailiang > Is this acceptable ? > >> Regards, >> Daniel >> >