Split

Definition

Signature

split(vs: set<set<VM>>)

• vs : a non-empty set of set of VMs for a meaningful constraint. VMs not in the Running state are ignored. Sets inside vs must be disjoint.

• s2 : an non-empty set of VMs for a meaningful constraint, that is distinct from s1. VMs not in the Running state are ignored.

The split constraint forces the given sets of VMs in vs to not share hosting servers. Each of the used servers can still host multiple VMs but they have to be in the same set.

Classification

• Primary users: application administrator
• Manipulated elements: VM placement
• Concerns: VM-to-VM placement, Partitioning, Fault tolerance

Usage

The split constraint deserves isolation requirements. Hypervisors are supposed to provide a strong isolation between the VMs. However, various attacks such as those based on VM escaping [50], allow to break this isolation to provide from a malicious VM, a non-legitimate access to the hypervisor or the other VMs. An application administrator may then want to have its VMs hosted on servers that do not host potentially malicious VMs. A split constraint may then be used to indicate the VMs that must be running on servers other than the supposed malicious ones.

The split constraint deserves also fault tolerance requirements. For high-availability purposes, replicated applications are supposed to be running on distinct servers. In this setting, an application administrator may use one split constraint to ensure all the VMs of the application do not share any server with the replicated VMs.

Example

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

N1: VM1 VM2

N2: VM3

N3: VM4 VM5

N4: VM6

N5: VM7 VM8

N1: VM1

N2: VM3

N3: VM2 VM4 VM5

N4: VM7 (VM6)

N5: VM8

Figure 7: A reconfiguration motivated by split constraints.

• split({{VM1,VM3},{VM2, VM4}}). This constraint was not satisfied in the source configuration as VM2 and VM1 were colocated despite they belong to different sets. This violation was fixed by relocating VM2 to N3.

• split({{VM5,VM6},{VM7, VM8}}). This constraint was satisfied in the source configuration as no set of VMs share hosts. The constraint is still satisfied in the destination configuration: despite VM7 and VM6 are on the same server, VM6 is not in the Running state, so it is ignored by the constraint.

See also

Related Constraints

• spread, lazySpread: These constraints disallow the colocation between VMs rather than groups of VMs. A split constraint is equivalent to a lazySpread constraint when the split constraint is made up with two sets of one VM each.

• splitAmong: This constraint forces several set of VMs to be hosted on distinct groups of servers among those explicitly allowed.

• lonely. The lonely constraint is a specialization of the split constraint that isolate a set of VMs from all the others. It can then be emulated using a split constraint when the second set of VMs is the absolution complement of the first one.

Specialization(s)

• To lonely: split({vs1,vs1}) ↔ lonely(vs1)

• To lazySpread: split(s/|s|) ↔ lazySpread(s)