[c-nsp] Rate-limiting VMs within the network

[Matthew Melbourne]

Hi,

I am looking seeking a mechanism to limit bandwidth utilised by
virtual machines on a given host on a per-VM basis within a hosting
environment. Ideally, any single VM should not be allowed to exceed an
outbound bandwidth utilisation of 100Mbps. The current solution uses
Microsoft Hyper-V and its virtual switch technology. The Hyper-V hosts
are connected into Cisco 2960G access switches which are then uplinked
to a redundant core of 6509 switches. I readily recognise an
alternative solution to this would be to use VMware/Cisco Nexus 1000V
instead to form a virtual distributed switch, but for this particular
project we are limited to using the MS Hyper-V solution.

We have no control of bandwidth utilisation within the MS Hyper-V
vSwitch (apparently, this functionality may appear at a later date),
so the expectation is that any rate-limiting could occur within the
network. However, multiple VMs are hosted on the same physical server,
and these VMs can move between hosts as resources are optimised, so
any classical “per-port” QoS policing is not likely to be
straightforward and isn’t likely to scale (the principle concerns are
the potential number of VMs and their mobility). To police on a per-IP
address basis, I'd expect to have to define many classes (one for each
VM) which, for potentially many hundreds (possibly thousands) of VMs
could be serious scalability issue.

An alternative solution we’ve been investigating into is “Per-User
Microflow Policing”, or User-Based Rate Limiting (UBRL), where we can
police based on source IP address. An acceptable solution would be to
limit each IP address within a certain range to use up to 100Mbps of
outbound bandwidth. However, it appears that UBRL and NetFlow (which
is also running on the core 6509s) are mutually exclusive when there
is a flow-mask conflict. Full NetFlow data needs to be retained by the
NetFlow collector for billing purposes.

Are there any other mechisms to achieve per-VM rate-limiting within
the network?

Cheers,

Matt

--
Matthew Melbourne