Re: [libvirt] [PATCH 0/7] Add support for setting QoS
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