On 24.06.2011 20:00, Christian Benvenuti (benve) wrote:
>> 3) Similarly for macvtap <network>s, will the
network-wide bandwidth
>> limiting be applied to the physical ethernet device? This would
>> have the side effect of including host traffic on that interface in
>> the bandwidth totals, but I don't see a way around it.
> With this patch as-is, shaping rules are applied only when creating
TAP
> devices. This mean only network types VIR_DOMAIN_NET_TYPE_NETWORK and
> VIR_DOMAIN_NET_TYPE_BRIDGE.
>>
>> 4) Finally on that topic, what about <network>s that have a pool of
>> physical ethernets to be used macvtap-style? Is there any way we can
>> do bandwidth limiting on an aggregated collection of network
interfaces?
>> Or
>> will attempts to configure this necessarily result in a "config not
>> supported" log message?
> Huh, I didn't know it is possible to have a pool of devices within one
> <network>. So in this case, this patch silently does nothing.
The IFB (Intermediate Functional Block) allows you to
configure aggregate QoS on multiple interfaces.
/Chris
Yes, but we would then need to create those IFB devices on the fly (e.g.
on domain startup) and I don't think there is other way than unloading
and then loading the ifb module (with different parameter) which however
would break other domains connections. Or am I missing something?
But I agree, using ifb would be much more beautiful, because we could
actually shape incoming traffic instead of dropping.
Michal