qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 0/7] Netfilter: Add each netdev a default fi


From: Hailiang Zhang
Subject: Re: [Qemu-devel] [PATCH RFC 0/7] Netfilter: Add each netdev a default filter
Date: Mon, 25 Jan 2016 09:59:01 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]