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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list