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?
2: http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/util/virnetdevbandwidth.c...