Hi Yiping, Anti-affinity groups deal with the placement of VMs when they are started, but doesn't/can't 'move' running VMs (it isn't like vSphere DRS). If you change a VM's anti-affinity group, it's current placement on a host may suddenly become invalid. As the Anti-Affinity group code isn't designed to move VMs, the safest option is to ensure that the VM is stopped when its group is changed so that when it is started again, CloudStack can then properly decide where it can/should go.
Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -----Original Message----- From: Yiping Zhang [mailto:yzh...@marketo.com] Sent: 10 January 2018 19:51 To: users@cloudstack.apache.org Subject: why instance must be stopped in order to update its affinity groups? Hi, List: Can someone please explain why a VM instance must be in stopped state when updating its affinity group memberships? This requirement is in “Feature assumptions” section of the original 4.2 design document (https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups). My users either don’t understand or don’t care about affinity groups and I see a large number of instances with sub-optimal host placement (from anti-host affinity group point of view). But it is too much trouble for me to coordinate with so many users to shut them down in order to fix their host placement. What bad things would happen if a running instance’s affinity group is changed? Thanks, Yiping
