Well, I am not a Java developer so this task is beyond my ability. But I am
more than willing to work with someone to come up with a feature
description/user story and test it when it becomes available if it ever reaches
that stage.
Thanks
Yiping
On 1/12/18, 7:10 AM, "Paul Angus"
It a high level that is quite possible to do. In practice there would be a
number of safety nets in place, staged moving of VMs is always a little fraught
without being able to reserve the resources ahead of time.
Are you volunteering to write it?
Kind regards,
Paul Angus
Paul, Marc:
Thanks for clarifying.
As cloud admin/operator, I do care about the instance’s placement and that is
why I’d like to apply affinity groups to all instances whenever possible.
It sounds like there is no fundamental technical reasons that a running
instance’s affinity group
Hi Yiping,
To add to Paul's comment, you also need to understand the goal of the
anti-affinity groups. If they don't care, you should simply block the
command so that your users don't use it (you should list the
createAffinityGroup command as a root admin call in the commands.properties
file by
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
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
