Browse Prior Art Database

Mechanism for VM Placement for High Availability and License Containment

IP.com Disclosure Number: IPCOM000243931D
Publication Date: 2015-Oct-28
Document File: 4 page(s) / 133K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to use host Dynamic Resource Scheduler (DRS) groups and Virtual Machine (VM) DRS groups to achieve the desired placement design so that the provisioning placement logic can satisfy all of the constraints for clustered and non-clustered workloads in VMware* virtualization.

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

Page 01 of 4

Mechanism for VM Placement for High Availability and License Containment

A core function in VMware* virtualization is a VMware cluster. A VMware cluster is pool of ESX* hosts. An ESX host can host multiple virtual machines (VMs). Within this pool of hosts, the virtual machines can be migrated from one host to another without service interruption; this function is called vMotion. The VMware Dynamic Resource Scheduler (DRS) utilizes vMotion to migrate idling or low-consumer VMs to another host in the event that a host is resource-constrained and a VM or several VMs on that host cannot be satisfied, but another host within that cluster has resources available.

Another function of VMware DRS is to evacuate a host for maintenance. VMware DRS migrates all VMs off that host. VMware High Availability (HA) is another feature from VMware. If one or multiple hosts crash, VMs that were residing on those hosts are restarted on remaining hosts within that ESX cluster. In order to allow VM migration by DRS within only certain hosts that are a subset off the cluster, VMware has created Host DRS Affinity. A VM DRS Group contains VMs and a Host DRS Group contains ESX Hosts. These two groups can then be linked with VMs and must run on host rule. The rule guarantees that VMs are only migrated onto host that is part of that Host DRS group, and VMware HA does not start these VMs on hosts that are not part of that group. The should run on host will try to ensure the containment within the group of hosts, but if no resources are available, then it allows the system to violate this rule. The must run on host rule will not allow violation of this rule at any time. Therefore, the Build Block (BB) containment groups are linked with should run on host rules so that it allows failover to the other building block in case of a building block failure. The license containment groups are linked to the must run on host rule in order to guarantee that these VMs never, ever run on any host that is not licensed. For example, if all hosts of that host DRS group have failed, then it starts the VMs on hosts that are not part of that Host DRS Group.

The problem is that VMware ESX does not have an understanding of physical location; some ESX hosts within an ESX cluster are located in one building block while others are located in another building block. For high availability (to protect against a building block failure), the VMs in a cluster have to be restricted to run on a sub-set of the hosts in the cluster. In addition to the physical separation problem, only a subset of hosts is licensed for particular workloads (e.g., Microsoft* SQL Database), and VMs running a licensed application must never run on hosts that are not licensed.

A mechanism/design is required so that the provisioning placement logic can satisfy both of the above constraints for clustered and non-clustered workloads.

The novel solution is a method to use host DRS groups and VM DRS groups to achieve the...