You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Yiping Zhang <yz...@marketo.com> on 2016/11/09 01:03:19 UTC
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
AW: API migrateVirtualMachine does not respect affinity group
assignment
Posted by "S. Brüseke - proIO GmbH" <s....@proio.com>.
We run into this "problem" too. Here are my 2 cents:
API call should respect affinity groups, but it should be able for administrator to force a migration (force=true).
As an administrator you cannot control (or have in mind) all affinity groups when you need to evacuate a host. At the moment you run into the situation that you migrate a vm to an host where another vm of the same affinity group is running. When you stop this vm you are unable to start it because then the affinity group kicks in.
Mit freundlichen Grüßen / With kind regards,
Swen
-----Ursprüngliche Nachricht-----
Von: Marc-Aurèle Brothier [mailto:marco@exoscale.ch]
Gesendet: Mittwoch, 9. November 2016 08:41
An: users@cloudstack.apache.org
Betreff: Re: API migrateVirtualMachine does not respect affinity group assignment
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 <sw...@ena.com> wrote:
> Can you open a jira issue on this?
>
> Simon Weller/ENA
> (615) 312-6068
>
> -----Original Message-----
> From: Yiping Zhang [yzhang@marketo.com]
> Received: Tuesday, 08 Nov 2016, 8:03PM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> 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
>
- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main
USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: API migrateVirtualMachine does not respect affinity group assignment
Posted by Marc-Aurèle Brothier <ma...@exoscale.ch>.
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 <sw...@ena.com> wrote:
> Can you open a jira issue on this?
>
> Simon Weller/ENA
> (615) 312-6068
>
> -----Original Message-----
> From: Yiping Zhang [yzhang@marketo.com]
> Received: Tuesday, 08 Nov 2016, 8:03PM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> 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
>
RE: API migrateVirtualMachine does not respect affinity group
assignment
Posted by Simon Weller <sw...@ena.com>.
Can you open a jira issue on this?
Simon Weller/ENA
(615) 312-6068
-----Original Message-----
From: Yiping Zhang [yzhang@marketo.com]
Received: Tuesday, 08 Nov 2016, 8:03PM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
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