Cliff notes for NetIOC. You can find a most excellent white paper describing this feature in 25 glorious pages here: VMware Network I/O Control, Architecture, Performance and Best Practices.
Prerequisites for NetIOC
NetIOC is only supported with the vNetwork Distributed Switch (vDS).
NetIOC Feature Set
NetIOC provides users with the following features:
• Isolation: ensure traffic isolation so that a given flow will never be allowed to dominate over others, thus preventing drops and
• Shares: allow flexible networking capacity partitioning to help users to deal with overcommitment when flows compete
aggressively for the same resources
• Limits: enforce traffic bandwidth limit on the overall vDS set of dvUplinks
• Load-Based Teaming: efficiently use a vDS set of dvUplinks for networking capacity
NetIOC Traffic Classes
The NetIOC concept revolves around resource pools that are similar in many ways to the ones already existing for CPU and Memory.
NetIOC classifies traffic into six predefined resource pools as follows:
• FT logging
• Virtual machine traffic
A user can specify the relative importance of a given resource-pool flow using shares that are enforced at the dvUplink level. The
underlying dvUplink bandwidth is then divided among resource-pool flows based on their relative shares in a work-conserving
way. This means that unused capacity will be redistributed to other contending flows and won’t go to waste. As shown in Figure 1,
the network flow scheduler is the entity responsible for enforcing shares and therefore is in charge of the overall arbitration under
overcommitment. Each resource-pool flow has its own dedicated software queue inside the scheduler so that packets from a given
resource pool won’t be dropped due to high utilization by other flows.
A user can specify an absolute shaping limit for a given resource-pool flow using a bandwidth capacity limiter. As opposed to shares
that are enforced at the dvUplink level, limits are enforced on the overall vDS set of dvUplinks, which means that a flow of a given
resource pool will never exceed a given limit for a vDS out of a given vSphere host.
Load-Based Teaming (LBT)
vSphere 4.1 introduces a load-based teaming (LBT) policy that ensures vDS dvUplink capacity is optimized. LBT avoids the situation of
other teaming policies in which some of the dvUplinks in a DV Port Group’s team were idle while others were completely saturated just
because the teaming policy used is statically determined. LBT reshuffles port binding dynamically based on load and dvUplinks usage
to make an efficient use of the bandwidth available. LBT only moves ports to dvUplinks configured for the corresponding DV Port
Group’s team. Note that LBT does not use shares or limits to make its judgment while rebinding ports from one dvUplink to another.
LBT is not the default teaming policy in a DV Port Group so it is up to the user to configure it as the active policy.
LBT will only move a flow when the mean send or receive utilization on an uplink exceeds 75 percent of capacity over a 30-second
period. LBT will not move flows more often than every 30 seconds.
NetIOC is configured through the vSphere Client in the Resource Allocation tab of the vDS from within the “Home->Inventory->Networking” panel.
NetIOC is enabled by clicking on “Properties…” on the right side of the panel and then checking “Enable network I/O control on this
vDS” in the pop up box.
That’s all folks. I’m out.