cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Ough <alex.o...@sungard.com>
Subject Re: A question on vm migrations when hosts are set into a maintenance mode.
Date Thu, 03 Oct 2013 16:44:46 GMT
I'm not sure what else commands 'MigrateCommand' actually execute in
addition to 'Start/Stop/CopyCommand', but can we include 'MigrateCommand'
if it consists of only those 3 commands?

Thanks
Alex Ough


On Thu, Oct 3, 2013 at 11:31 AM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> On 10/3/13 9:25 AM, "Koushik Das" <koushik.das@citrix.com> wrote:
>
> >Alena,
> >I see that you had added this config setting. Any specific reason that
> >this only for Start/Stop/Copy and not for all the commands as Alex
> >mentioned? The name of the setting looks generic.
>
> Because these are the commands for which hypervisors support parallel
> execution for sure (tested by QA on Xen/KVM/VmWare).
>
> As all our commands are generic, and not hypervisor specific, you have to
> be very careful if decide to enable parallel execution for MigrateCommand
> and test it on all the hypervisors CS supports.
>
> -Alena.
>
> >
> >-Koushik
> >
> >On 03-Oct-2013, at 8:10 PM, Alex Ough <alex.ough@sungard.com> wrote:
> >
> >> Hi Koushik,
> >>
> >> Thanks for your reply, but unfortunately, this setting does NOT cover
> >> 'MigrateCommand'.
> >> As you specified, it seems to be effective only in
> >>Start/Stop/CopyCommand.
> >>
> >> So can we include 'MigrateCommand' in that setting?
> >>
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Wed, Oct 2, 2013 at 11:44 PM, Koushik Das <koushik.das@citrix.com>
> >>wrote:
> >>
> >>> It is already a global setting in 4.2. The name of the setting is
> >>> "execute.in.sequence.hypervisor.commands".
> >>>
> >>> Check out Config.java
> >>>
> >>>    ExecuteInSequence("Advanced", ManagementServer.class, Boolean.class,
> >>> "execute.in.sequence.hypervisor.commands", "true", "If set to true,
> >>> StartCommand, StopCommand, CopyCommand will be synchronized on the
> >>>agent
> >>> side." +
> >>>    " If set to false, these commands become asynchronous. Default value
> >>> is true.", null),
> >>>
> >>>
> >>> -Koushik
> >>>
> >>> On 02-Oct-2013, at 10:43 PM, Alex Ough <alex.ough@sungard.com<mailto:
> >>> alex.ough@sungard.com>> wrote:
> >>>
> >>> Thanks for the reply, Marcus.
> >>>
> >>> What about the option #3, which is to make it as a global setting?
> >>> I think it can prevent side effects if exist.
> >>>
> >>> Alex Ough
> >>>
> >>>
> >>> On Wed, Oct 2, 2013 at 11:37 AM, Marcus Sorensen <shadowsor@gmail.com
> >>> <mailto:shadowsor@gmail.com>>wrote:
> >>>
> >>> Not sure. I don't know the history well enough to know if there were
> >>> issues in the past, it might be that some hypervisors were fine and
> >>> others weren't.
> >>>
> >>> On Wed, Oct 2, 2013 at 9:21 AM, Alex Ough
> >>><alex.ough@sungard.com<mailto:
> >>> alex.ough@sungard.com>> wrote:
> >>> Marcus/Kelven,
> >>>
> >>> Any thoughts on my suggestions?
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough
> >>><alex.ough@sungard.com<mailto:
> >>> alex.ough@sungard.com>>
> >>> wrote:
> >>>
> >>> Oh, sorry for the confusion. I must have reversed the flags.
> >>> As Kelven pointed, it is set as 'TRUE', which makes the process as
> >>> sequential.
> >>>
> >>> So my questions are
> >>> 1. If there is any reason why the method have been defined to return
> >>> 'TRUE' always?
> >>> 2. Do we expect any side effects and/or malfunctioning if we change it
> >>> to
> >>> returning 'FALSE'?
> >>> 3. For a resolution without breaking possible flows, can we add the
> >>> value
> >>> of 'executeInSequence' to the global setting if #2 answers YES?
> >>>
> >>>
> >>> On Tue, Sep 24, 2013 at 11:19 AM, Marcus Sorensen <shadowsor@gmail.com
> >>> <mailto:shadowsor@gmail.com>>
> >>> wrote:
> >>>
> >>> I thought executeInSequence of 'true' made it go serially, or
> >>> sequentially. In my codebase for 4.1,4.2,master it's been 'true' since
> >>> August of 2010:
> >>>
> >>> 2010-08-11 09:13:29 -0700 19) public class MigrateCommand extends
> >>> Command
> >>> {
> >>> 2010-08-11 09:13:29 -0700 20)     String vmName;
> >>> 2010-08-11 09:13:29 -0700 21)     String destIp;
> >>> 2011-08-10 10:26:04 -0700 22)     String hostGuid;
> >>> 2010-08-11 09:13:29 -0700 23)     boolean isWindows;
> >>> 2010-08-11 09:13:29 -0700 24)
> >>> 2010-08-11 09:13:29 -0700 25)
> >>> 2010-08-11 09:13:29 -0700 26)     protected MigrateCommand() {
> >>> 2010-08-11 09:13:29 -0700 27)     }
> >>> 2012-12-03 22:06:41 -0800 28)
> >>> 2010-08-11 09:13:29 -0700 29)     public MigrateCommand(String vmName,
> >>> String destIp, boolean isWindows)
> >>> 2010-08-11 09:13:29 -0700 30)         this.vmName = vmName;
> >>> 2010-08-11 09:13:29 -0700 31)         this.destIp = destIp;
> >>> 2010-08-11 09:13:29 -0700 32)         this.isWindows = isWindows;
> >>> 2010-08-11 09:13:29 -0700 33)     }
> >>> 2012-12-03 22:06:41 -0800 34)
> >>> 2010-08-11 09:13:29 -0700 35)     public boolean isWindows() {
> >>> 2010-08-11 09:13:29 -0700 36)         return isWindows;
> >>> 2010-08-11 09:13:29 -0700 37)     }
> >>> 2012-12-03 22:06:41 -0800 38)
> >>> 2010-08-11 09:13:29 -0700 39)     public String getDestinationIp() {
> >>> 2010-08-11 09:13:29 -0700 40)         return destIp;
> >>> 2010-08-11 09:13:29 -0700 41)     }
> >>> 2012-12-03 22:06:41 -0800 42)
> >>> 2010-08-11 09:13:29 -0700 43)     public String getVmName() {
> >>> 2010-08-11 09:13:29 -0700 44)         return vmName;
> >>> 2010-08-11 09:13:29 -0700 45)     }
> >>> 2012-12-03 22:06:41 -0800 46)
> >>> 2011-08-10 10:26:04 -0700 47)     public void setHostGuid(String guid)
> >>> {
> >>> 2011-08-10 10:26:04 -0700 48)         this.hostGuid = guid;
> >>> 2011-08-10 10:26:04 -0700 49)     }
> >>> 2012-12-03 22:06:41 -0800 50)
> >>> 2011-08-10 10:26:04 -0700 51)     public String getHostGuid() {
> >>> 2011-08-10 10:26:04 -0700 52)         return this.hostGuid;
> >>> 2011-08-10 10:26:04 -0700 53)     }
> >>> 2010-08-11 09:13:29 -0700 54)
> >>> 2010-08-11 09:13:29 -0700 55)     @Override
> >>> 2010-08-11 09:13:29 -0700 56)     public boolean executeInSequence() {
> >>> 2010-08-11 09:13:29 -0700 57)         return true;
> >>> 2010-08-11 09:13:29 -0700 58)     }
> >>> 2010-08-11 09:13:29 -0700 59) }
> >>>
> >>> On Tue, Sep 24, 2013 at 9:58 AM, Chip Childers
> >>> <chip.childers@sungard.com<mailto:chip.childers@sungard.com>>
wrote:
> >>> Hey Kelven - This topic was discussed briefly in the past [1].  Are
> >>> you
> >>> able to provide any thoughts on Alex's ideas below?
> >>>
> >>> -chip
> >>>
> >>>
> >>> [1] http://markmail.org/message/fznrszaswruvlmuy
> >>>
> >>>
> >>>
> >>> On Tue, Sep 24, 2013 at 10:53:04AM -0500, Alex Ough wrote:
> >>> For a resolution without breaking possible flows, I'd like to add
> >>> the
> >>> value
> >>> of 'executeInSequence' to the global setting.
> >>> Is there any reason not to do this?
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Mon, Sep 23, 2013 at 12:57 PM, Alex Ough
> >>><alex.ough@sungard.com<mailto:
> >>> alex.ough@sungard.com>>
> >>> wrote:
> >>>
> >>> All,
> >>>
> >>> After a little more investigation, I found that the
> >>> 'MigrateCommand'
> >>> defined its 'executeInSequence' method to return 'FALSE', which
> >>> seems to
> >>> make the vm migrations as serial even if the migration requests
> >>> are
> >>> dispatched to ha_worker in parallel.
> >>> You can confirm this in line 56 of
> >>> '/cloudstack/core/src/com/cloud/agent/api/MigrateCommand.java'
> >>>
> >>> So my question is if there is any reason why the method have been
> >>> defined to return 'FALSE' always?
> >>> And do we expect any side effects and/or malfunctioning if we
> >>> change
> >>> it to
> >>> returning 'TRUE'?
> >>>
> >>> Any answers/comments will be very appreciated.
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Wed, Sep 18, 2013 at 10:22 AM, Alex Ough <
> >>> alex.ough@sungard.com<mailto:alex.ough@sungard.com>>
> >>> wrote:
> >>>
> >>> I checked the vm migration when their host is set to a
> >>> maintenance
> >>> mode
> >>> and found that even if the orchestration layer fires the each vm
> >>> migration
> >>> at the same time using a ha_worker thread, the actual migration
> >>> seems to be
> >>> executed serially.
> >>>
> >>> Is this what we expect? And if so, any chance to make the actual
> >>> migrations in parallel?
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message