Using CPU limits in vCloud for NFV

Looking at the VMware vCloud for NFV proposition, you will notice that vCloud Director (vCD) is one of the options for the Virtualized Infrastructure Manager (VIM) layer based on the ETSI framework.

VMware vCloud NFV supports two integrated virtualized infrastructure managers (VIMs): native VMware vCloud Director or VMware Integrated OpenStack, a full OpenStack implementation that is completely tested and integrated. Both VIMs support templated service descriptions as well as multi-tenancy and robust networking, enabling the automation of on-boarding VNFs with the acceleration of configuring and allocating compute, storage and networking resources.

As mentioned, vCD is used for multi tenancy and providing a management layer for the tenants to spin up new workloads within their own set of resources. Now how the compute resources are provided to the workloads is very interesting in some telco workload cases. vCD provides three different ways to deliver compute resources to the tenant vApps:

  • Allocation Pool
    A percentage of the resources you allocate are committed to the Organization virtual DataCenter (OvDC). You can specify the percentage, which allows you to overcommit resources.
  • Pay-As-You-Go
    Allocated resources are only committed when users create vApps in the OvDC. You can specify the maximum amount of CPU and memory resources to commit to the OvDC.
  • Reservation Pool
    All of the resources you allocate are committed to the OvDC.

More information on allocation models in vCD can be found on Duncan’s blogpost, its one of his older posts but still accurate. The Pay-As-You-Go allocation model seems to be a popular choice because it enforces the entitlement for specific resources per Virtual Machine (VM). It does so by setting a reservation and a limit on each VM in the vApp / OvDC using a configurable vCPU speed. That means a VM can only consume CPU cycles as configured in the OvDC. See the following example to get a better feeling on what is configurable within a Pay-As-You-Go OvDC.


Now, bring the fact that limits and reservations are placed on a VM back to the fact that network I/O and the required CPU time to process that network I/O is accounted to the VM. Check the Virtual Machine Tx threads explained post to get a better understanding of how the VMkernel behaves when VMs transmit network packets. Because the CPU cycles used by the Tx threads are accounted to the VM, you should be very careful with applying CPU limits to the VM. CPU limits can seriously impact the network I/O performance and packet rate capability!

A severe performance impact can be expected when you deploy NFV Telco workloads that are known for high network utilization when using CPU limits. A clear example is a virtual Evolved Packet Core (vEPC) node, for instance the Packet Gateway (PGW). VMs used in these nodes are known to have a large appetite for network I/O and may be using Intel DPDK to thrive network packet rates.

Several vCPUs in the VMs will be configured in DPDK to poll a queue. Those vCPUs will claim all the cycles they can get their hands on! You should combine that with the additional CPU time required to process the transmitted network I/Os to fully understand the behaviour of such a VM and its need for CPU time. Only then can you make the correct decisions related to allocation models.

So be aware of the possible implications that CPU limits may introduce on network performance. Maybe it is better for certain telco NFV workloads to opt for another allocation model.

More information on how the VMware vCloud for NFV proposition is helping the telco industry and the LTE/4G and 5G innovations is found here: Be sure to check it out!

Read More

VMworld 2017 session picks

VMworld is upon us. The schedule builder went live and boy am I excited about VMworld 2017!


This year Frank and I are presenting the successor of last years session at both VMworlds. We are listed in the schedule builder as SER1872BU – vSphere 6.5 Host Resources Deep Dive: Part 2. We are planning to bring even more ESXi epicness with a slight touch of vSAN and networking information that allows you to prep ESXi to run NFV workloads that drive IoT innovations. Last year we were lucky to have packed rooms in Vegas and Barcelona.

The enthusiasm about our book witnessed so far shows us there is still a lot of love out there for the ESXi hypervisor and ‘under-the-hood’ tech! We are working hard on having an awesome session ready for you!

VMworld Session Picks

This year I want to learn more about NFV, IoT and Edge as I find innovation in these areas intriguing. I found some sessions that look to be very interesting. I supplemented these with talks held by industry titans about various topics. If my schedule lets me, I want to see the following sessions:

  • Leading the 5G and IoT Revolution Through NFV [FUT3215BUby Constantine Polychronopoulos
  • vSAN at the Edge: HCI for Distributed Applications Spanning Retail to IoT [STO2839GU] by Kristopher Groh
  • VMware Cloud Foundation Futures [PBO2797BU] by Raj Yavatkar
  • Machine Learning and Deep Learning on VMware vSphere: GPUs Are Invading the Software-Defined Data Center [VIRT1997BU] by Uday Kurkure and Ziv Kalmanovich
  • Managing Your Hybrid Cloud with VMware Cloud on AWS [LHC2971BU] by Frank Denneman and Emad Younis
  • The Top 10 Things to Know About vSAN [STO1264BU] by Duncan Epping and Cormac Hogan

There are way more interesting sessions going on! Be sure to find and schedule your favorite ones as rooms tend to fill up quickly!

See you in Vegas and Barcelona!!


Read More

Virtual Machine Tx threads explained

Looking at the ESXi VMkernel network path you will notice it consists of Netpoll threads and Tx threads. Netpoll threads receive traffic from an ESXi host perspective where Tx threads transmit data from a VM to another VM or physical component.

By default, each VM is armed with only one Tx thread. As network packets are transmitted from the VM towards the pNIC layer via the VMkernel, ESXi consumes CPU cycles. These cycles, or CPU time, will be accounted to the VM itself. Tx threads are identified in esxtop in the CPU view as NetWorld-VM-XXX. This ensure that you to have a clear picture on what the costs are of transmitting large numbers of networks packets from that specific VM. It allows you to have a better understanding if a VM is constrained by the amount of CPU time that is spent on transmission of data.

Again, only one Tx thread is spun up by default. That correlates with one CPU core. This is why the NetWorld will not trespass the ±100% of %USED.

In the screenshot above, the VM in question was running the transmit side of the packet-generator test. The NetWorld-VM-69999 world was constantly running up to 100%. This is a clear example of a VM being constrained by only one Tx thread. A relatively quick solution is to add an additional Tx thread. You can add more as needs require. Looking at the network view in esxtop, you will be able to see what vNIC is processing the largest amount of network I/O. In this specific case, we knew exactly what vNIC was in extra need of network processing power.

Additional Tx threads

You can add an additional Tx thread per vNIC. This is configured as an advanced parameter in the VM configuration. The ethernetX.ctxPerDev = 1 advanced setting is used for this. The ‘X’ stands for the vNIC for which the parameter is set. You can configure each vNIC with a separate Tx thread. However, that will create unnecessary Tx threads in your VM and potentially consume CPU time in an inefficient way, because not every vNIC is likely to require its own Tx thread. It really is a setting that is driven by demand. If your workload running in the VMs has a large appetite for network I/O, take a closer look at what vNIC could benefit from additional Tx threads.

Once the additional Tx thread(s) are configured, you want to verify that it is activated. Additional Tx threads will appear in esxtop in the CPU view as NetWorld-Dev-<id>-Tx. By being added as a separate world, a clear overview can be generated on which NetWorld is processing the majority of network I/O as a result of the CPU usage associated with that thread.

In this screenshot, you will notice that the additional Tx thread is active and processing network I/O. This is one way to determine if your advanced setting is working correctly. You can also use a net-stats command to do so.

More information…

…can be found in the vSphere 6.5 Host Resources Deep Dive book that is available on Amazon!

Read More