The diagram at left should be familiar to most. When using 1GigE NICs, ESX hosts are typically deployed with NICs dedicated to particular traffic types. For example you may dedicate 4x 1GigE NICs for VM traffic; one NIC to iSCSI, another NIC to vMotion, and another to the service console. Each traffic type gets a dedicated bandwidth by virtue of the physical NIC allocation.
Moving to the diagram at right … ESX hosts deployed with 10GigE NICs are likely to be deployed (for the time being) with only two 10GigE interfaces. Multiple traffic types will be converged over the two interfaces. So long as the load offered to the 10GE interfaces is less than 10GE, everything is ok—the NIC can service the offered load. But what happens when the offered load from the various traffic types exceeds the capacity of the interface? What happens when you offer say 11Gbps to a 10GigE interface? Something has to suffer. This is where Network IO Control steps in. It addresses the issue of oversubscription by allowing you to set the relative importance of predetermined traffic types.
NetIOC is controlled with two parameters—Limits and Shares.
Limits, as the name suggests, sets a limit for that traffic type (e.g VM traffic) across the NIC team. The value is specified in absolute terms in Mbps. When set, that traffic type will not exceed that limit *outbound* (or egress) of the host.
Shares specify the relative importance of that traffic type when those traffic types compete for a particular vmnic (phyiscal NIC). Shares are specified in abstract units numbered between 1 and 100 and indicate the relative importance of that traffic type. For example, if iSCSI has a shares value of 50, and FT logging has a shares value of 100, then FT traffic will get 2x the bandwidth of iSCSI when they compete. If they were both set at 50, or both set at 100, then they would both get the same level of service (bandwidth).
There are a number of preset values for shares ranging from low to high. You can also set custom values. Note that the limits and shares apply to output or egress from the ESX host, not input.
Remember that shares apply to the vmnics; limits apply across a team.
