[libvirt] traffic control

[Michal Privoznik]

On 17.05.2013 13:07, Peter V. Saveliev wrote:
> …
> 
> Hello.
> 
> I would like to start a discussion about network SLA mechs in libvirt.
> 
> Right now, as I understand, libvirt is managing traffic controls, e.g.
> bandwitdh limitation, calling external routines (ip/tc). This approach
> has its own drawbacks, including the need to parse text output of
> external commands and also some complexity with the current state
> identification — the queueing discipline can be changed on the interface
> in runtime outside of libvirt.
> 
> But I would like to propose another approach — not dropping the previous
> one, just as an option, maybe. Not so long time ago I started a project
> [1] that works with netlink directly and can provide standalone daemon,
> that manages interface properties, including queueing disciplines.
> Working with netlink events, it is in permanent sync with the current
> interface statuses w/o any polling. So maybe it would make sense to use
> this daemon — e.g. with JSON or XML-RPC over SSL/TLS, or with any other
> RPC that's preferred by libvirt.
> 
> That approach can provide:
> 
> * more high-level API, that will keep libvirt off the need to compute
> rule and filter handlers, hierarchy and so on — we would be able to
> implement more complex traffic control schemes in more easy way
> 
> * generally speaking, an RPC API is more easy to use, than the execution
> of external binary file and parsing text output, and `tc` is not the
> easiest command to automate.

In fact, there's currently no 'tc' output parsing at all. None is
needed. When setting QoS, libvirt just flushes all previous settings and
insert its own. I don't think libvirt can guarantee things like minimal
throughput if we let other applications to interfere with libvirt QoS
settings. So our reason should be slightly different: offloading QoS
setting to a external application which in turn allows us to create even
more complicated QoS tree. This would be a reasonable trade off.

> 
> If it sounds reasonably enough, we can discuss the overall scheme,
> communication and API details that would be more comfortable to libvirt
> and so on.

Regarding communication with your daemon we have 2 options:

a) A monitor to which libvirt would connect

b) A C library containing APIs that libvirt would call (internally, they
will just hide a) and wrap it into a C function anyway).

Since your application is pure python, going with b) would be like
learning a tux to fly :) Hence I vote for a). Regarding protocol format,
I prefer JSON as libvirt already has capability of parsing it and
creating new messages. The other option is XML.

Currently, the 'tc' is used to manage all three QoS objects: qdisc,
class and filter. Take look at [2] to see the most complicated QoS tree
that libvirt creates. Honestly, I am not sure how to catch that into an
API calls.

Michal

> 
> So, any comments?
> 
> [1] — https://github.com/svinota/pyroute2
2:
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virnetdevbandwidth.c;h=ccc1449d7695253845e1f138ffebf0500a448eca;hb=HEAD#l96