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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list