Vmware, Inc.

Xunjia Lu

Haoqiang Zheng

Petr Vandrovec

Bi Wu

Yao Zhang

Mukund Gunti

Zhelong Pan

Xavier Deguillard

Olivier Alain Cremel

Vishnu Sekhar

Timothy Merrifield

James White

David A Dunn

Boon Seong Ang

Rishi Mehta

Fred Jacobs

Yifan Hao

Various approaches for exposing a virtual Non-Uniform Memory Access (NUMA) locality table to the guest OS of a VM running on NUMA system are provided. These approaches provide different tradeoffs between the accuracy of the virtual NUMA locality table and the ability of the system's hypervisor to migrate virtual NUMA nodes, with the general goal of enabling the guest OS to make more informed task placement/memory allocation decisions.

Virtual non-uniform memory access (NUMA) locality table for NUMA systems

Techniques for optimizing virtual machine (VM) scheduling on a non-uniform cache access (NUCA) system are provided. In one set of embodiments, a hypervisor of the NUCA system can partition the virtual CPUs of each VM running on the system into logical constructs referred to as last level cache (LLC) groups, where each LLC group is sized to match (or at least not exceed) the LLC domain size of the system. The hypervisor can then place/load balance the virtual CPUs of each VM on the system's cores in a manner that attempts to keep virtual CPUs which are part of the same LLC group within the same LLC domain, subject to various factors such as compute load, cache contention, and so on.

Optimizing virtual machine scheduling on non-uniform cache access (NUCA) systems

Techniques for concurrently supporting virtual non-uniform memory access (virtual NUMA) and CPU/memory hot-add in a virtual machine (VM) are provided. In one set of embodiments, a hypervisor of a host system can compute a node size for a virtual NUMA topology of the VM, where the node size indicates a maximum number of virtual central processing units (vCPUs) and a maximum amount of memory to be included in each virtual NUMA node. The hypervisor can further build and expose the virtual NUMA topology to the VM. Then, at a time of receiving a request to hot-add a new vCPU or memory region to the VM, the hypervisor can check whether all existing nodes in the virtual NUMA topology have reached the maximum number of vCPUs or maximum amount of memory, per the computed node size. If so, the hypervisor can create a new node with the new vCPU or memory region and add the new node to the virtual NUMA topology.

Techniques for concurrently supporting virtual NUMA and CPU/memory hot-add in a virtual machine

An example method of managing exclusive affinity for threads executing in a virtualized computing system includes: determining, by an exclusive affinity monitor executing in a hypervisor of the virtualized computing system, a set of threads eligible for exclusive affinity; determining, by the exclusive affinity monitor, for each thread in the set of threads, impact on performance of the threads for granting each thread exclusive affinity; and granting, for each thread of the set of threads having an impact on performance of the threads less than a threshold, exclusive affinity to respective physical central processing units (PCPUs) of the virtualized computing system.

Opportunistic exclusive affinity for threads in a virtualized computing system

Some embodiments provide a method for scheduling networking threads associated with a data compute node (DCN) executing at a host computer. When a virtual networking device is instantiated for the DCN, the method assigns the virtual networking device to a particular non-uniform memory access (NUMA) node of multiple NUMA nodes associated with the DCN. Based on the assignment of the virtual networking device to the particular NUMA node, the method assigns networking threads associated with the DCN to the same particular NUMA node and provides information to the DCN regarding the particular NUMA node in order for the DCN to assign a thread associated with an application executing on the DCN to the same particular NUMA node.

Optimized networking thread assignment

Disclosed are various approaches to anticipating future resource consumption based on user sessions. A message comprising a prediction of a future number of concurrent user sessions to be hosted by a virtual machine within a predefined future interval of time is received. It is then determined whether the future number of concurrent user sessions will cause the virtual machine to cross a predefined resource threshold during the predefined future interval of time. Then, a message is sent to a first hypervisor hosting the virtual machine to migrate the virtual machine to a second hypervisor.

Anticipating future resource consumption based on user sessions

A method of selectively assigning virtual CPUs (vCPUs) of a virtual machine (VM) to physical CPUs (pCPUs), where execution of the VM is supported by a hypervisor running on a hardware platform including the pCPUs, includes determining that a first vCPU of the vCPUs is scheduled to execute a latency-sensitive workload of the VM and a second vCPU of the vCPUs is scheduled to execute a non-latency-sensitive workload of the VM and assigning the first vCPU to a first pCPU of the pCPUs and the second vCPU to a second pCPU of the pCPUs. A kernel component of the hypervisor pins the assignment of the first vCPU to the first pCPU and does not pin the assignment of the second vCPU to the second pCPU. The method further comprises selectively tagging or not tagging by a user or an automated tool, a plurality of workloads of the VM as latency-sensitive.

Fine-grained application-aware latency optimization for virtual machines at runtime

Disclosed are various embodiments that utilize conflict cost for workload placements in datacenter environments. In some examples, a protected memory level is identified for a computing environment. The computing environment includes a number of processor resources. Incompatible processor workloads are prohibited from concurrently executing on parallel processor resources. Parallel processor resources share memory at the protected memory level. A number of conflict costs are determined for a processor workload. Each conflict cost is determined based on a measure of compatibility between the processor workload and a parallel processor resource that shares a particular memory with the respective processor resource. The processor workload is assigned to execute on a processor resource associated with a minimum conflict cost.

Workload placement using conflict cost

The disclosure provides a method of performing a workload on a virtual machine (VM) executing on a host comprising one or more physical central processing units (pCPUs) is provided. The method further includes setting a quality of service (QoS) metric associated with the VM, the QoS metric indicating a time period. The method further includes setting a bandwidth metric associated with the VM, the bandwidth metric indicating a percentage. The method further includes allocating by a central processing unit (CPU) scheduler to a virtual CPU (vCPU) of the VM one of the one or more pCPUs periodically every time period, wherein for every time period the one of the one or more pCPUs is allocated to the vCPU for a duration that is the percentage of the time period based on the QoS metric and the bandwidth metric. The method further includes executing the workload on the virtual machine with the vCPU according to the allocation of the one or more pCPUs.

Virtual processor allocation with execution guarantee

The disclosure provides techniques for scheduling a jitterless workload on a virtual machine (VM) executing on a host comprising one or more pCPUs comprising a first subset of the one or more pCPUs and a second subset of the one or more pCPUs. The techniques further include creating a jitterless zone, wherein the jitterless zone includes the first subset of the one or more pCPUs. The techniques further include determining whether a vCPU of the VM is used to execute a jitterless workload or a non-jitterless workload. The techniques further include allocating by a CPU scheduler to the vCPU at least one of the pCPUs in the jitterless zone when the vCPU of the VM is used to execute a jitterless workload. The techniques further include scheduling the jitterless workload for execution by the vCPU on the allocated at least one of the pCPUs in the jitterless zone.

A computer system is rebooted upon crash without running platform firmware and without retrieving all of the modules included in a boot image from an external source and reloading them into system memory. The reboot process includes the steps of stopping and resetting all of the processing units, except one of the processing units that detected the crash event, selecting the one processing unit to execute a reboot operation, and executing the reboot operation to reboot the computer system.

Efficient reboot of an operating system

An approach for providing low-latency and fast response times required by virtual machine (VM) telecommunication (telco) workloads is disclosed. In one embodiment, a kernel scheduler identifies hypervisor system contexts that are outside of traditional virtual central processing unit (CPU) contexts and servicing telco workloads. The scheduler grants each such context exclusive affinity to a respective physical CPU, up to a configurable maximum number of such grants. The scheduler also increases the CPU reservations in a system resource pool for the hypervisor by one CPU, indicating that there is one fewer physical CPU on which VMs may be placed or moved. The exclusive affinities and CPU reservations may be dynamically adjusted as, e.g., new latency-sensitive VMs are powered on with virtual CPUs that need to be granted exclusive affinity to physical CPUs or contexts no longer relevant to telco workloads are demoted to not have exclusive affinity to physical CPUs.

Growing community of inventors

Los Altos, CA, United States of America

Xunjia Lu