Affinity / Anti-affinity Rules

1 Background

Currently, there is no way for a user to let CloudStack know how to place a certain VM in relationship to other VMs.

Use Cases:

Deploying a n-Tier App: When a user wants to deploy a n-Tier App, they might not want VMs in the same Tier to be either on the same host or even on the same POD. This is one of the ways they can get even more high availability within a zone.
User who is deploying multiple VMs as part of an application deployment might have some application restrictions to have VMs running as close to each other as possible.
Web VMs in a Basic Zone: For users deploying multiple Web VMs in a Basic zone, they might want to ensure that all web VMs are on as far apart as possible for higher availability.

Customer Benefits:

Allowing users to configure affinity/anti-affinity gives the users the capability to increase the reliability of an application even if it deployed within a same zone.

Feature needs to be supported on Basic as well as Advanced zones
Users should be allowed to configure affinity and anti-affinity while creating or updating VMs
For each VM, users should be able to provide both (Affinity VMs and Anti-affinity VMs) lists concurrently. For example, VM-A can have affinity with VMs B & C and anti-affinity with VMs D & E at the same time.
When configuring Affinity / anti-affinity for a VM, users should be allowed to provide a list of affinity / anti-affinity VMs (via API) or select affinity /anti-affinity VMs from a list (via UI)
Configuration needs to be done only on one of the VMs and it should automatically be displayed for all VMs involved. If VM A is configured to have affinity / anti-affinity with VM B & C, then users should be able to see the same rule when editing VM B & C via UI.

As part of VM creation/update wizards, users should be provided with the following:
- Choice to enable affinity and/or anti-affinity rules
- If enabled, users should be provided with a list of VMs to select from

Following upgrade scenarios should be supported: