From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNWSm-0004Rl-Sb for qemu-devel@nongnu.org; Sun, 24 Jan 2016 21:01:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNWSj-0001it-NE for qemu-devel@nongnu.org; Sun, 24 Jan 2016 21:01:04 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:46839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNWSi-0001iI-U0 for qemu-devel@nongnu.org; Sun, 24 Jan 2016 21:01:01 -0500 References: <1453451811-11860-1-git-send-email-zhang.zhanghailiang@huawei.com> <20160122100756.GD14825@redhat.com> <56A20604.4000407@huawei.com> <20160122103858.GE14825@redhat.com> From: Hailiang Zhang Message-ID: <56A58165.8070503@huawei.com> Date: Mon, 25 Jan 2016 09:59:01 +0800 MIME-Version: 1.0 In-Reply-To: <20160122103858.GE14825@redhat.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/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. Is this acceptable ? > Regards, > Daniel >