Improvements to anti-affinity layers

In private cloud, to create VMs that will always deploy on separate hypervisor hosts, use anti-affinity layers in your virtual appliance. Each VM in a layer will deploy on a different vCenter host. Each VM can be in one layer only.

The privileges to work with this feature are Manage virtual appliances and Manage layers.

When you create a new layer, you can add one or more VMs. Abiquo will create the layer when you deploy the first VM. You can also add VMs to an existing layer and move powered off VMs between layers. When you delete the last VM, Abiquo will delete the layer from the DRS.

In the vCenter hosts plugin, you cannot move a deployed VM to a different layer because the VM is already assigned to a host in the set of hosts for the layer.

In vCenter cluster, you can change the layer even if the VM is deployed. The rule is enforced at power on, so after you move a VM to another layer, you will not be able to power it on if that would break the anti-affinity rule.

Abiquo will identify the layer with the IDs of the entities and the layer name, and it will add the names of the enterprise and VApp at first deploy. An example could be 1-300 (enterprise name-virtualappliance name) layer name. The vCenter operator can change the part inside the () as required without affecting the layer functionality.

In vCenter, Abiquo creates a DRS rule for 'Separate Virtual Machines' in Cluster - Configuration - VM/Host Rules.

Upgrades from previous versions

Abiquo does not support an upgrade of layers from previous version. We recommend that you delete all layers in the database by updating layer to set it to null for all VMs and then recreate the layers.

General limitations of the layers feature

If there are any problems when configuring an anti-affinity rule, the VM may still deploy without the rule but Abiquo may create a WARN event.

Abiquo does not onboard layers. When Abiquo retrieves VMs from vCenter, it does not check if the VM belongs to any groups. And Abiquo will not update after changes in vCenter (such as deleting a rule, or removing/adding a VM to a rule).

The operation to 'separate VMs' is not infallible, and a rule can have 'conflicts' if there are other rules affecting the same VMs. Abiquo only allows a VM to be in a single rule, so it does not track or report conflicts.

Abiquo does not support local datastores in a cluster, because if you deploy to a local datastore, then that would limit the DRS actions and it may prevent the correct implementation of the anti-affinity layers.

Abiquo does not support hot-reconfigure of VM layers. You cannot modify VM layers when the VMs are powered on.

You cannot rename a layer with deployed VMs, but you can move the VMs to another layer with a different name.

If you rename an enterprise or a VApp, then Abiquo does not update the rule, but the vCenter administrator can rename the part of the rule with the names and this will not affect the layer functionality.

Implementation notes about anti-affinity layers

When you power on a VM, Abiquo will also make a new request to findRulesForVm before it powers on the VM, and this request displays in vCenter task list.

Abiquo checks for rule violations by looking for all the connected hosts in the cluster (also including hosts in maintenance mode, and hosts that are not accepting new deploys, but could contain an existing VM).

The Abiquo team detected some issues with concurrency when rapidly deploying many VMs in a layer, so when you power on a VM with a rule, Abiquo will perform a random wait (with a maximum of 8s).