Re: [libvirt] traffic control
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/virnetdevbandwidt...