vmware: affinity and anti-affinity rules must be followed when VMware cluster DRS is enabled

[shwstppr]

ISSUE TYPE

• Improvement Request

COMPONENT NAME

VMware

CLOUDSTACK VERSION

NA

CONFIGURATION

Advanced zone with vSphere Datacenter, multiple ESXi 6.7 hosts
DRS enabled on the vSphere cluster

OS / ENVIRONMENT

N/A

SUMMARY

When the vSphere cluster has DRS enabled, VMs created from CloudStack with anti-affinity rules get migrated to the same host(s) by the VMware. This makes use of affinity groups useless at CloudStack end when DRS is enabled in VMware.

STEPS TO REPRODUCE

1. Enable DRS at VMware end, have sufficient load that it can kick in
2. Create an affinity group with type anti-affinity
3. Deploy multiple VMs using that group
4. Observe VMs getting started on different hosts
5. When DRS kicks in, VMs may get migrated depending on load-balancing
6. CloudStack updates new host for the VM on power sync 

EXPECTED RESULTS

VM remains on different hosts

ACTUAL RESULTS

VMs end up on same host(s)

[DaanHoogland]

I'm not sure if we can do anything but make this known by documentation, or at best made mutually exclusive features by configuration.

[aleskxyz]

I'm not sure if we can do anything but make this known by documentation, or at best made mutually exclusive features by configuration.

@DaanHoogland
Or we can delegate management of VM placement to vmware as it already has this feature:
https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html

[DaanHoogland]

good point @aleskxyz , thanks. This worth some investigation. @shwstppr had you looked into this as well?
So if the zone is a vphere dc, antiaffinity should be ignored by the deployment planner but instead it should be configured on vcenter.
important:

 Note:

If you use the vSphere HA Specify Failover Hosts admission control policy and designate multiple failover hosts, VM-VM affinity rules are not supported.

I think it must be possible to call that procedure

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html

in an automated fashing on rule creation and than add and remove VMs from it at will.

[nvazquez]

Hi @shwstppr is there any work made on this issue?

[rohityadavcloud]

None I checked, it may be scheduled to be fixed @nvazquez

[nvazquez]

@sureshanaparti can you explore and advise about the proposed procedure https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html ?

[sureshanaparti]

@sureshanaparti can you explore and advise about the proposed procedure https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html ?

@nvazquez vSphere cluster supports multiple VM Rules to keep VMs together (affinity) and separate VMs (anti-affinity), so each affinity / anti-affinity group from CloudStack can be created / mapped to a VM rule in vSphere cluster (with name as the affinity / anti-affinity group name in CloudStack). The VM(s) created from CloudStack can be added to / removed from the VM rule in that vSphere cluster, based on the affinity / anti-affinity group of the VM. For workaround, the operator can now create similar VM rules in vSphere cluster and add / remove VMs to / from these rules.

[nvazquez]

Thanks @sureshanaparti - not including this one on the 4.16 milestone after your remark