Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: An example method of virtualized cache allocation for a virtualized computing system includes: providing, by a hypervisor for a virtual machine (VM), a virtual shared cache, the virtual shared cache backed by a physical shared cache of a processor; providing, by the hypervisor to the VM, virtual service classes and virtual service class bit masks; mapping, by the hypervisor, the virtual service classes to physical service classes of the processor; associating, by the hypervisor, a shift factor with the virtual service class bit masks with respect to physical service class bit masks of the processor; and configuring, by the hypervisor, service class registers and service class bit mask registers of the processor based on the mapping and the shift factor in response to configuration of the virtual shared cache by the VM.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: An example method of determining size of virtual last-level cache (LLC) exposed to a virtual machine (VM) supported by a hypervisor executing on a host computer includes: obtaining, by the hypervisor, a host topology of the host computer, the host topology including a number of LLCs in a central processing unit (CPU) of the host computer and a host LLC size being a size of each of the LLCs in the CPU; obtaining, by the hypervisor, a virtual socket size for a virtual socket presented to the VM by the hypervisor and a virtual non-uniform memory access (NUMA) node size presented to the VM by the hypervisor; determining, by the hypervisor, a virtual LLC size for the VM based on the host topology, the virtual socket size, the virtual NUMA node size, and a plurality of constraints; and presenting, to the VM, the virtual LLC size in processor feature discovery information.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.