Vmware, Inc.

Zhelong Pan

Rajesh Venkatasubramanian

Pranshu Jain

Haoqiang Zheng

Fei Guo

Sahan Bamunavita Gamage

Sabareesh Subramaniam

Varun S Lingaraju

Badhrinath Sampathkumar

Jiaojiao Song

Inna Rytsareva

Thaleia Dimitra Doudali

Charan K Singh

Yao Zhang

Adrian Drzewiecki

Benjamin J Corrie

Olivier Alain Cremel

Mark Russell Johnson

Xunjia Lu

Aalap Desai

Rahul Chandrasekaran

Julien Freche

Anant Agarwal

Vikram Nair

Lei Lu

Matthew Kim

Prashanth Victor

Xiaoyuan Lu

Bing Hu

Dragos Misca

Jianxiong Jiang

Various examples are disclosed for performing cross-cluster load balancing. In some aspects, a workload is selected for cross-cluster migration. A destination cluster is identified for a migration of the workload from a source cluster to the destination cluster. A cross-cluster migration recommendation is generated to migrate the workload from the source cluster to the destination cluster.

Cross-cluster load balancer

The present disclosure relates generally to virtualization, and more particularly to techniques for deploying containers in a virtual environment. The container scheduling can be based on information determined by a virtual machine scheduler. For example, a container scheduler can receive a request to deploy a container. The container scheduler can send container information to the virtual machine scheduler. The virtual machine scheduler can use the container information along with resource utilization of one or more virtual machines to determine an optimal virtual machine for the container. The virtual machine scheduler can send an identification of the optimal virtual machine back to the container scheduler so that the container scheduler can deploy the container on the optimal virtual machine.

Techniques for container scheduling in a virtual environment

Examples described herein include systems and methods for prioritizing workloads, such as virtual machines, to enforce quality of service ('QoS') requirements. An administrator can assign profiles to workloads, the profiles representing different QoS categories. The profiles can extend scheduling primitives that can determine how a distributed resource scheduler (“DRS”) acts on workloads during various workflows. The scheduling primitives can be used to prioritize workload placement, determine whether to migrate a workload during load balancing, and determine an action to take during host maintenance. The DRS can also use the profile to determine which resources at the host to allocate to the workload, distributing higher portions to workloads with higher QoS profiles. Further, the DRS can factor in the profiles in determining total workload demand, leading to more efficient scaling of the cluster.

Quality of service scheduling with workload profiles

Various examples are disclosed for cluster resource management using adaptive memory demands. In some examples, a local memory estimate is determined for a workload. The local memory estimate is determined using a memory reclamation parameter for the workload executed by a current host of the workload. A destination memory estimate is also determined for the workload. The destination memory estimate is determined using a full memory estimate unreduced by memory reclamation parameters. The workload is executed using a host that is selected in view of an analysis that uses the local memory estimate for the current host and the destination memory estimate for at least one destination host.

Cluster resource management using adaptive memory demand

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 restarting a virtual machine (VM) running in a cluster in a first data center, in a second data center, includes: transmitting images of VMs, including a first VM, running in the cluster of hosts at a first point in time to the second data center for replication in the second data center; generating difference data representing a difference in an image of the first VM at a second point in time and the image of the first VM at the first point in time; transmitting the difference data to the second data center; setting the first VM to be inactive in the first data center; and communicating with a control plane in the second data center to set as active, and power on, a VM in the second data center using the replicated image of the first VM updated with the difference data.

Cloud restart for VM failover and capacity management

Various examples are disclosed for placing virtual machine (VM) workloads in a computing environment. Ephemeral workloads can be placed onto reserved instances or reserved hosts in a cloud-based VM environment. If a request to place a guaranteed workload is received, ephemeral workloads can be evacuated to make way for the guaranteed workload.

Cost-savings using ephemeral hosts in infrastructure as a service environments based on health score

Various aspects are disclosed for unified resource management of containers and virtual machines. A podVM resource configuration for a pod virtual machine (podVM) is determined using container configurations. The podVM comprising a virtual machine (VM) that provides resource isolation for a pod based on the podVM resource configuration. A host selection for the podVM is received from a VM scheduler. The host selection identifies hardware resources for the podVM. A container scheduler is limited to bind the podVM to a node corresponding to the hardware resources of the host selection from the VM scheduler. The podVM is created in a host corresponding to the host selection. Containers are started within the podVM. The containers correspond to the container configurations.

Unified resource management for containers and virtual machines

Examples described herein include systems and methods for efficiently scaling an SDDC. An example method can include storing resource utilization information for a variety of resources of the SDDC. The example method can also include predicting a future resource utilization rate for the resources and determining that a predicted utilization rate is outside of a desired range. The system can determine how long it would take to perform the scaling, including adding or removing a host and performing related functions such as load balancing or data transfers. The system can also determine how long the scaling is predicted to benefit the SDDC to ensure that the benefit is sufficient to undergo the scaling operation. If the expected benefit is greater than the benefit threshold, the system can perform the scaling operation.

Predictive scaling of datacenters

Load balancing across hosts in a computer system is triggered based on pairwise comparisons of resource utilization at different host. A method for load balancing across hosts includes the steps of determining a resource utilization difference between first and second hosts, wherein the first host has a higher resource utilization than the second host, comparing the resource utilization difference against a threshold difference, and upon determining that the resource utilization difference exceeds the threshold difference, selecting a workload executing in the first host for migration to the second host.

Pairwise comparison and migration of workloads for load balancing

A method of restarting a virtual machine running in a cluster of hosts in a first data center, in a second data center, wherein each virtual machine is assigned a priority level, includes: transmitting virtual machines images running in the cluster at a first time to the second data center; selecting virtual machines to be restarted in the second data center according to priority levels assigned; and for each selected virtual machine, (a) generating difference data in an image of the selected virtual machine at a second time and at the first time, (b) transmitting the difference data to the second data center, (c) setting the virtual machine inactive in the first data center, and (d) communicating with the second data center to set as active; and power on, a virtual machine in the second data center using the image of the virtual machine transmitted to the second data center.

Cloud restart for non-critical performance virtual machines

Disclosed are various embodiments for distributing the load of a plurality of virtual machines across a plurality of hosts. A potential new host for a virtual machine executing on a current host is identified. A gain rate associated with migration of the virtual machine from the current host to the potential new host is calculated. A gain duration associated with migration of the virtual machine from the current host to the potential new host is also calculated. A migration cost for migration of the virtual machine from the current host to the potential new host, the migration cost being based on the gain rate and the gain duration is determined. It is then determined whether the migration cost is below a predefined threshold cost. Migration of the virtual machine from the current host to the optimal host is initiated in response to a determination that the migration cost is below the predefined threshold.

Growing community of inventors

Cupertino, CA, United States of America

Zhelong Pan