[libvirt] traffic control

[Daniel P. Berrange]

On Fri, May 17, 2013 at 01:07:02PM +0200, 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.

If an administrator is changing stuff managed by libvirt behind its
back, all bets are off & they are on their own when things break.
The same as if you go making sending commands to the QEMU monitor
directly, or do any number of other things. So the traffic
shaping code really isn't unique in this respect, and doesn't
need special handling to deal with that.

> 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.

Actually the 'tc' command is pretty trivial to use & we don't
need to parse text output from it at all.

> 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.

The idea of handing off this to an external python daemon isn't
really very appealing to me, because I don't really like libvirt
core functionality depending on anything python related.

Really libvirt should just talk network directly rather than
invoking the 'tc' command, or there could be a low level C
library that could be used instead of 'tc'. I don't think we
need to hand this off to a daemon at all.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|