SingleCapacity

Definition

Signature

singleCapacity(s:set<server>, nb:number, r:string)

• s: a non-empty set of servers for a meaningful constraint. Servers not in the Online state are ignored.

• r : a resource identifier such as mem, ucpu, pcpu or vm to identify the physical memory, the computational capacity, the physical CPUs or the number of hosted VMs, respectively.

• nb: a positive amount of resources.

The singleCapacity constraint restricts to a maximum of nb, the amount of a specific resource of type r that can be used on each of the online servers in s to run VMs.

Classification

• Primary users: datacenter administrator
• Manipulated elements: VM placement, Resource allocation
• Concerns: Resource management, VM-to-server placement

Usage

The singleCapacity constraint is used by a datacenter administrator to indicate to the VM manager, the practical amount of resources on each server, that will be available to the VMs. As an example, a server having 4 GB of RAM running a Xen hypervisor [7] cannot offer this amount of memory to the VMs as the Domain-0 requires memory resources to run. Using a singleCapacity constraint, the datacenter administrator may then declare the practical amount of memory that will be available to the VMs by removing the amount used by the Domain-0.

Management operations, such as migrations, requires CPU resources on the involved servers. When every resources are devoted to the running VMs, a migration will alter their performance as the hypervisor will use a significant amount of the resources that was allotted to the VMs, to manage the migration. Using singleCapacity constraints, the datacenter administrator may prevent this temporary performance loss by dedicating in advance some resources to the hypervisor. Typically a core or a CPU, to let it perform the management operations without impacting the running VMs.

Example

Figure 18 depicts a sample reconfiguration between a source and a destination configuration where each server provides 8 unit of CPU and 7 unit of memory resources to VMs. Each VM is associated to a gray rectangle that denotes its resource usage. In this setting, the following singleCapacity constraints were considered :

figure 18: A reconfiguration motivated by singleCapacity constraints.

• singleCapacity({N1, N3},4,"mem"). This constraint was not satisfied in the source configuration as the memory usage by the VMs on N1 and N3 equals 4 and 5, respectively. This violation was fixed by relocating VM4 to N2 to liberate some resources.

• singleCapacity({N1, N2},8,"ucpu"). This constraint was satisfied in the source configuration as the UCPU consumption of the running VMs was equals to 7 at maximum. The constraint is still satisfied in the destination configuration as the relocation of VM4 to N2 makes the UCPU resource usage of N2 to 8, the maximum allowed.

• singleCapacity({N3},1,"vm"). This constraint was not satisfied in the source configuration as the number of VMs running on N3 was 2. The reconfiguration process fixed this violation by relocating VM4 to N2.

See also

Related Constraints

• cumulatedCapacity: This constraint can be used when the resource restriction is related to the aggregation of some servers' resources.

• preserve: This constraint can be used in addition of singleCapacity constraint to ensure every VM has a sufficient amount of resources to run at peak level, according to the resources made available by singleCapacity constraints.

Reformulation(s)

• Using cumulatedCapacity: singleCapacity(ns, nb, r) ↔ ∀n ∈ ns, cumulatedCapacity({n}, nb, r)