[libvirt] [PATCH 0/7] Add support for setting QoS

[Michal Privoznik]

On 23.06.2011 19:17, Laine Stump wrote:
> On 06/23/2011 11:36 AM, Michal Privoznik wrote:
>> This patch series add support for setting traffic shaping and policing
>> on both domain's interface and network's virtual bridge. Basically,
>> this is done via 'tc' from iproute2 package. For shaping is HTB used,
>> for policing we need u32 match selector. Both should be available in
>> RHEL-6 kernel.
> 
> Some general questions:
> 
> 1) Just to make sure I understand it, if <bandwidth> is specified in the
> network XML, that will be applied to the bridge itself, not to each
> interface on the bridge. (So, if we want to have the per-guest bandwidth
> specified in a single place, that will be where my proposed <portgroup>
> comes in - a <bandwidth> specified in a <portgroup> will be applied
> individually to each guest interface that is part of the portgroup.)
Yes. If I want to support per-guest traffic shaping in these patches, I
need to create a separate XML for that. Neither <network> nor <domain>
is not the right place. So I'd end up with the same structure as you.
> 
> 2) Following on (2). Once host bridges (ie, a bridge device that's
> directly connected to a physical NIC) are available as <network>s, can
> the limiting then be applied to the bridge device, or will it instead
> need to be applied to the ethernet device that the bridge is using to
> attach to the physical network? If the latter is the case, then we'll
> need a way to determine which device that is (currently I hadn't planned
> on putting that information in the XML, because it's configured outside
> of libvirt, and this could lead to mismatches between what libvirt XML
> shows and reality).
Fortunately, it is the first case. Therefore is XML inserted into
<interface> and <network>. Rules are applied only on desired device. Not
anywhere else.
> 
> 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.
> 
> 5) I see you've put the data structures and parsing/formatting functions
> that are used by both network_conf.c and domain_conf.c in the util
> directory. I've been wondering myself what to do with similar
> structs/functions that will be used in both network and domain XML (eg,
> <virtualport> will soon be used by both) - does everyone agree this is
> the right way to handle it? Or should there be a common file in the conf
> directory instead? (I don't have an opinion, but want to "do the right
> thing" when I write my own code)
Yeah, I was thinking the same way. When I wrote the code, I've decided
for src/util. But I would not hesitate if somebody wants it in src/conf.

Michal