The BtrPlace Constraints Catalog

Preserve

Definition

Signature

preserve(s : set<VM>, r:string, n : number)

s: a non-empty set of VMs for a meaningful constraint. VMs not in the Running state are ignored.
r : a resource identifier such as mem, ucpu, pcpu to identify the physical memory, the computational capacity, the physical CPUs, respectively.
n: a positive amount of resources

The preserve constraint ensures each running VM in s is hosted on a server having at minimum an amount of resource of type r equals to n dedicated to the VM.

Classification

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

Usage

The preserve constraint allows to control the resource allocated to the given VMs. This constraint may first be used inside a provisioning algorithm developed by an application administrator to indicate to the resource manager an ideal amount of resources to provide to the VMs to let them work at a peak level of performance.

Inside a non-conservative consolidated environment, a server may host several VMs that currently ask for a small amount of resources. In this situation, the server may become saturated if VMs ask suddenly for a little more resources. This situation is not idyllic as these micro variations may lead to numerous relocations. To prevent that situation and reduce the frequency of the reconfigurations, the datacenter administrator may use one preserve constraint to over-allocate a minimum amount of resources to the VMs that ask for a small amount of resources.

Example

Figure 14 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 requirement, expressed using preserve constraints. A rectangle overlapping another one on a dimension indicates the two associated VMs have to share resources. This reveals an overloaded server. Figure 3.15 depicts the associated event-based reconfiguration plan. The following preserve constraints were considered:

figure 14: A reconfiguration motivated by preserve constraints.

Ø	relocate(VM6)
!relocate(VM6)	relocate(VM7)
!relocate(VM7)	relocate(VM4)

Figure 3.15: Event-based reconfiguration plan.

preserve({VM2, VM3},4,"ucpu"). This constraint was not satisfied in the source configuration as the hosting servers of the given VMs do not provide enough resource to them: N1 provides 8 unit of CPU resources but VM6 requires 5 units and VM2 requires 4 units . In addition, VMs on N2 required 10 units of CPU resources. These violation were fixed by relocating VM4 and VM6 to N3 and N4, respectively. However, N4 does not initially provides enough resources to host simultaneously VM4 and VM7. It has then be decided to relocate first VM6 to N4Êto liberate enough resource on N1 to host VM7. Once this relocation terminated, enough resources were available on N3 to host VM4.
preserve({VM1, VM7, VM5},2,"mem"). This constraint was satisfied in the source configuration as their hosting servers provided enough memory resources to meet their requirement. The constraint is still satisfied in the destination configuration despite the relocation of VM7.