IMHO it's something desirable, because in case of emergency, it's better to migrate a VM to a host that does not follow the anti affinity group, rather than leaving the VM on a host that must be shutdown for example and loosing the VM. It's up to the admin to make this transgression during the shortest amount of time. Those migration API calls are always done by an admin, and therefore should take care of such case, which is not very complicated. I have a python script that does the job ( https://gist.github.com/marcaurele/dc1774b1ea13d81be702faf235bf2afe) for live migration for example.
On Wed, Nov 9, 2016 at 2:47 AM, Simon Weller <[email protected]> wrote: > Can you open a jira issue on this? > > Simon Weller/ENA > (615) 312-6068 > > -----Original Message----- > From: Yiping Zhang [[email protected]] > Received: Tuesday, 08 Nov 2016, 8:03PM > To: [email protected] [[email protected]] > Subject: API migrateVirtualMachine does not respect affinity group > assignment > > Hi, > > It seems that the API migrateVirtualMachine does not respect instance’s > affinity group assignment. Is this intentional? > > To reproduce: > > Assigning two VM instances running on different hosts, say v1 running on > h1 and v2 running on h2, to the same affinity group. In GUI, it won’t let > you migrate v1 and v2 to the same host, but if you use cloudmonkey, you > are able to move both instances to h1 or h2 with migrateVirtualMachine API > call. > > IMHO, the API call should return with an error message that the migration > is prohibited by affinity group assignment. However, if the current > behavior is desirable in some situations, then a parameter like > ignore-affinity-group=true should be passed to the API call (or vice versa, > depending on which behavior is chosen as the default) > > Yiping >
