Re: [Xen-users] XCP bandwidth management

[Alexandre Bezroutchko <abb@xxxxxxxxx>]

Do you know of any better documentation for the ovs-vsctl? Maybe there is an answer there but I can't seem to find a full syntax explanation :(

I have found a lot of useful info here http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf (also see http://openvswitch.org/?page_id=14). I don't expect you will find a full solution there.

For the sFlow collector, it's one we wrote ourselves...not really too sure it's working right though because we seem to get multiple readings for the same interface. Also, not sure how to stop it being easily floodable (sFlow would be in a domU so if another domU floods it with these sFlow packets it would screw up the results I guess).

Would creating a dedicated network for sFlow-collector domU solve the problem? Normally your management network should be isolated from untrusted domUs already, so you could use it for sFlow-collector domU too.

I guess the ideal solution for me would be to have a VM guest that logs all the traffic, does some calculations. I want to check if the VM is averaging too fast across the month to meet its monthly target, and if it is,slow it down until the target is met (using 95 percentile perhaps to ignore spikes of activity).

Really don't know how to achieve that with what's available :(

As far as I can see, there are three pieces in this puzzle: 1) traffic usage metering; 2) control algorithm to decide when it is time to apply a quota; 3) policing mechanism to cap the bandwidth of the offending VMs

Problem #1 is pretty much solved. It can be done with sFlow collector or like this http://www.falsyana.com/2011/loeniks/xenserver-customization-bandwidth/. I currently use approach similar to the latter, but I save interface counters in RRD files, for the history.

Exact solution for problem #2 will probably vary greatly from installation to installation. Effectively we are talking about developing a system which takes set of timestamped values (vm_uud; vif_uud; rx_bytes; tx_bytes) as input and produces (vif_uuid; ingress_poliing_rate; ingress_poliing_burst) values as output.

Regarding problem #3 -- it is easy to limit traffic from VM, I trust it is possible to limit it in other direction too, but I didn't have enough time to make it work. One catch with limiting egress traffic is that here we actually have no control over how much stuff Internet hosts send to the IP address of VM. By limiting we are talking about dropping the excess of the traffic and hoping TCP will throttle down accordingly, which normally it will do.

Another aspect of problem #3 is how to transfer the policy from sFlow domU to dom0. I would do it by publishing desired policy on sFlow domU. It can be a simple as putting a plain text file on HTTP server, or maybe having LDAP server on sFlow domU, if it is justified. Then a cron job in dom0 would poll the desired policy from sFlow domU and reconfigure vswitch accordingly. Alternatively, one can push the config from sFlow domU into dom0 over native vSwitch API, but I feel it is less preferable from security point of view. I would prefer to keep my dom0 shut, even from trusted systems I own.

Wanna trade ;) your sFlow collector for vif script patch? The patch does bandwidth limiting (hardcoded value) and MAC/IP spoofing and ARP poisoning protection (allowed IP taken from VM other-config parameter). Actually I was going to publish the it anyway, if there is any interest...

Cheers,
Alex

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users