Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

vSphere Race Condition Mitigation

IP.com Disclosure Number: IPCOM000243899D
Publication Date: 2015-Oct-27
Document File: 5 page(s) / 137K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a generalized mechanism for achieving serialization in vSphere* when the target system is subject to race conditions caused by multiple concurrent requests initiated by tools in a clustered configuration.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 38% of the total text.

Page 01 of 5

vSphere Race Condition Mitigation

To place a virtual machine (VM) into a container, the Dynamic Resource Schedule (DRS) Affinity group, or Datastore Cluster, employs a two-step process. It must determine what is there and then place it. The use cases for Host Affinity group and Datastore Cluster are a little bit different.

A cloud environment might have multiple concurrent requests for provisioning virtual servers. In a virtualized X environment, this can lead to race conditions when the provisioning software selects a vSphere* Host Affinity group or a data store cluster. These race condition scenarios are distinct; the details are described below.

The novel contribution is a generalized mechanism for achieving serialization when the target system is subject to race conditions caused by multiple concurrent requests initiated by tools in a clustered configuration.

DRS Affinity Group Placement


Dynamic Resource Schedule (DRS) is a core function of vSphere. A number of physical hosts are grouped into an ESX cluster; DRS can move virtual machines without service interruption from one host to another within the cluster. A DRS Affinity Group is a group of hosts within that cluster and a group of virtual machines. With a DRS Affinity Group, a subset of hosts can be defined in which the DRS only moves the virtual machine of that group. For example, the cluster has hosts 1, 2, 3, and 4, but the DRS Host Affinity Group only hosts 1 and 2. Now, the DRS VM Affinity Group has VM A, B, and C defined. A DRS Affinity rule defines that VMs of that VM group must run only on hosts of that host group. As a result, the DRS moves VMs A, B, and C only between hosts 1 and 2; all other VMs can move between all hosts.

The problem here is that the Application Programming Interface (API) provided by VMware does not offer a method that simply adds a new virtual machine to the group of existing virtual machines. The API only offers the ability to edit a group (i.e. the entire group); previous virtual machines plus new virtual machines have to be provided as a parameter. This forces the provisioning software to first gather the current virtual machines of this group, then add the new virtual machine to this array of virtual machines, and then pass it to the edit method to modify the group to contain the previous plus the new virtual machines.

In a cloud environment, an instance of multiple requests coming from users that belong to different customers (and do not know of each other) results in multiple concurrent requests. If, for example, two concurrent requests are both trying to place a virtual machine in the same DRS Affinity Group, then the request that places it in a virtual machine is lost in the process. As an example, if three virtual machines (VM), VM A, VM B, and VM C, are currently part of the DRS Affinity Group and each request queries for the current list of VMs, then both requests will receive A, B, C as a result. Now, one request wants to place V...