Re: why instance must be stopped in order to update its affinity groups?

[Yiping Zhang]

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"  wrote:

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.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: 11 January 2018 19:16
To: users@cloudstack.apache.org
Subject: Re: why instance must be stopped in order to update its affinity 
groups?

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 membership can’t be updated.  Then why not allow this 
operation?  The logic could be as simple as follows:

If current host placement is compatible with new affinity group’s placement:
then 
   let the update succeed
else
   if auto-migration is true && there is a suitable host to migrate to
   then
  live migrate instance to new host and update instance’s affinity 
group membership
   else
  raise an exception
   end
end

Here “auto-migrate” is controlled by a new global setting parameter, and it 
is for migrating VM to another host in the same cluster. IOW, it does not 
involve storage migration.  If for some technical reasons that live migration 
can’t be done here, then that inner “if ... else ... end” block can be reduced 
to just “raise an exception”.

Is this reasonable?

Yiping

On 1/11/18, 12:19 AM, "Marc-Aurèle Brothier"  wrote:

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 changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure 
that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> 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 

RE: why instance must be stopped in order to update its affinity groups?

[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.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: 11 January 2018 19:16
To: users@cloudstack.apache.org
Subject: Re: why instance must be stopped in order to update its affinity 
groups?

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 membership can’t be updated.  Then why not allow this 
operation?  The logic could be as simple as follows:

If current host placement is compatible with new affinity group’s placement:
then 
   let the update succeed
else
   if auto-migration is true && there is a suitable host to migrate to
   then
  live migrate instance to new host and update instance’s affinity group 
membership
   else
  raise an exception
   end
end

Here “auto-migrate” is controlled by a new global setting parameter, and it is 
for migrating VM to another host in the same cluster. IOW, it does not involve 
storage migration.  If for some technical reasons that live migration can’t be 
done here, then that inner “if ... else ... end” block can be reduced to just 
“raise an exception”.

Is this reasonable?

Yiping

On 1/11/18, 12:19 AM, "Marc-Aurèle Brothier"  wrote:

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 changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> 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
>
>

Re: why instance must be stopped in order to update its affinity groups?

[Yiping Zhang]

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 membership can’t be updated.  Then why not allow this 
operation?  The logic could be as simple as follows:

If current host placement is compatible with new affinity group’s placement:
then 
   let the update succeed
else
   if auto-migration is true && there is a suitable host to migrate to
   then
  live migrate instance to new host and update instance’s affinity group 
membership
   else
  raise an exception
   end
end

Here “auto-migrate” is controlled by a new global setting parameter, and it is 
for migrating VM to another host in the same cluster. IOW, it does not involve 
storage migration.  If for some technical reasons that live migration can’t be 
done here, then that inner “if ... else ... end” block can be reduced to just 
“raise an exception”.

Is this reasonable?

Yiping

On 1/11/18, 12:19 AM, "Marc-Aurèle Brothier"  wrote:

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 changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> 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
>
>

Re: why instance must be stopped in order to update its affinity groups?

[Marc-Aurèle Brothier]

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 changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> 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
>
>

RE: why instance must be stopped in order to update its affinity groups?

[Paul Angus]

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

why instance must be stopped in order to update its affinity groups?

[Yiping Zhang]

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