Gather

Definition

Signature

gather(s : set<VM>)

• s : a set of at least 2 VMs for a meaningful constraint. VMs not in the Running state are ignored.

The gather constraint forces all the running VMs in the set s to be hosted on the same server.

Classification

• Primary users: application administrator
• Manipulated elements: VM placement
• Concerns: Performance, VM-to-VM placement

Usage

The gather constraint may first be used by an application administrator to force the colocation of strongly communicating VMs. Using one gather constraint, the VMs will be running on a same server and the virtual network between them will be embedded into the internal network provided by the hypervisor instead of the physical network, leading to better network performance.

The gather constraint may also be used by an application administrator to force the colocation of VMs that have to share a component such as a filesystem. Without any guarantee of colocation, it is a necessary to rely on a distributed filesystem or a file server which provide less performance than a raw and direct access to the data. Using the colocation guarantee provided by a gather constraint, the filesystem may be placed directly on the hosting server to achieve better performance. In this context, it is also often desirable to use one cstr: root]root constraint to prevent from VMs relocation.

It has however to be noticed that these usages ask explicitly for the VMs colocation. It is then not allowed to host the VMs on several servers when the colocation is not possible. The application administrator should then not over-estimate his needs to prevent him from having its VMs not running at all.

Example

Figure 9 depicts a sample reconfiguration between a source and a destination configuration. In this example, the following gather constraints were considered:

• gather({VM1, VM4}). This constraint was satisfied in the source configuration as only VM1 was running, so considered in the constraint. The constraint is also satisfied in the destination configuration: during the reconfiguration, VM4 was set in the Running state and deployed on N1 according to the constraint requirement.

• gather({VM2, VM5}). This constraint was not satisfied in the source configuration as VM4 and VM5 were running on different servers. The reconfiguration fixed this violation by relocating VM2 to N3 which is also hosting VM5.

• gather({VM3, VM6}). This constraint was satisfied in the source configuration as both VMs were running on N2. Despite both VMs were relocated during the reconfiguration process, the constraint is still satisfied in the destination configuration as both VMs are running on N4 and the end of reconfiguration.

N1: VM1 VM2

N2: VM3 VM6

N3: VM5

N4:

? : VM4

N1: VM1 VM4

N2:

N3: VM5 VM2

N4: VM3 VM6

? :

Figure 9: A reconfiguration motivated by gather constraints.

See also

Related Constraints

• spread, lazySpread: the opposite constraints of gather that force the VMs to be hosted on distinct servers.

Reformulation(s)

• Using among: gather(s) ↔ among(s,N/|N|)