From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZ7T-0007yP-KW for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:39:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMZ7Q-0001Jt-Dv for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:39:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMZ7Q-0001Jp-8N for qemu-devel@nongnu.org; Fri, 22 Jan 2016 05:39:04 -0500 Date: Fri, 22 Jan 2016 10:38:58 +0000 From: "Daniel P. Berrange" Message-ID: <20160122103858.GE14825@redhat.com> References: <1453451811-11860-1-git-send-email-zhang.zhanghailiang@huawei.com> <20160122100756.GD14825@redhat.com> <56A20604.4000407@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56A20604.4000407@huawei.com> Subject: Re: [Qemu-devel] [PATCH RFC 0/7] Netfilter: Add each netdev a default filter Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hailiang Zhang Cc: jasowang@redhat.com, hongyang.yang@easystack.cn, peter.huangpeng@huawei.com, zhangchen.fnst@cn.fujitsu.com, qemu-devel@nongnu.org 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 ? Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|