You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alex Ough <al...@sungard.com> on 2013/10/02 17:21:59 UTC
Re: A question on vm migrations when hosts are set into a maintenance mode.
Marcus/Kelven,
Any thoughts on my suggestions?
Thanks
Alex Ough
On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough <al...@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 <sh...@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
>> <ch...@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 <al...@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 <al...@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
>> >> >>
>> >> >
>> >> >
>>
>>
>
Re: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Prasanna Santhanam <ts...@apache.org>.
Cc Alena,
I just recalled that Alena was working with sending hypervisor
commands from cloudstack in parallel to the agent. She might have some
idea about why getExecuteInSequence() defaults to all commands going
in parallel now for VirtualMachineManager
On Mon, Nov 18, 2013 at 08:16:57AM -0600, Alex Ough wrote:
> Thank Parasanna & Sebastien,
> I also got his email and sent an email.
> Waiting for his reply...
>
> Thanks
> Alex Ough
>
>
> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>wrote:
>
> > cc Alex Huang to get his attention:
> >
> >
> > On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
> >
> > > Alex, Could you just do a git blame on the file and copy the emails of
> > > people who changed that bit of code? They may be able to help if Cc-ed
> > > directly.
> > >
> > > Thanks,
> > >
> > > On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> > >> I hate to sending the same emails over and over again, but I really
> > need to
> > >> finalize this feature to be included in the next code freeze because
> > this
> > >> feature is very critical in our inside project.
> > >>
> > >> Anyone who can help, please?
> > >> Thanks
> > >> Alex Ough
> > >>
> > >>
> > >> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
> > wrote:
> > >>
> > >>> Not sure if Alex Huang checked this, but can anyone help to resolve
> > this?
> > >>>
> > >>> Thanks
> > >>> Alex Ough
> > >>>
> > >>>
> > >>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
> > wrote:
> > >>>
> > >>>> It sounds a little scary...
> > >>>>
> > >>>> I looked at the history and found these.
> > >>>>
> > >>>> 8/9/ : file moved to engine by Alex Huang
> > >>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> > >>>> 'getExecuteInSequence()' by Alex Huang
> > >>>>
> > >>>>
> > >>>> Hi Alex Huang,
> > >>>> I'm not sure if you're aware of this, but can you check this for me?
> > >>>>
> > >>>> Thanks
> > >>>> Alex Ough
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
> > shadowsor@gmail.com>wrote:
> > >>>>
> > >>>>> I'm not sure. I know in the past when I've seen files change
> > locations
> > >>>>> it has also clobbered updates to that file. Someone branched, did the
> > >>>>> reorganization work, and merged, while in-between the original file
> > >>>>> changed.
> > >>>>>
> > >>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
> > >>>>> wrote:
> > >>>>>> All,
> > >>>>>>
> > >>>>>> While merging my changes to 4.3 branch, I found that the option,
> > >>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
> > >>>>> Start/Stop/Copy
> > >>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
> > >>>>>>
> > >>>>>>
> > >>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> > >>>>>>
> > >>>>>> *protected boolean getExecuteInSequence() {*
> > >>>>>> * return false;*
> > >>>>>> *}*
> > >>>>>>
> > >>>>>> As you see in the above, the function, 'getExecuteInSequence', just
> > >>>>> returns
> > >>>>>> false instead of getting the value from the global variable.
> > >>>>>>
> > >>>>>> And one more change is that the file has been moved to
> > >>>>>> 'engine/orchestration/src/com/cloud/vm' from
> > 'server/src/com/cloud/vm'.
> > >>>>>>
> > >>>>>> Am I missing something related with this or do we stop supporting
> > this
> > >>>>>> option in 4.3?
> > >>>>>> I'm a little confused, so please help me resolve this.
> > >>>>>>
> > >>>>>> Thanks
> > >>>>>> Alex Ough
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> Thanks a lot for your confirmation, Marcus.
> > >>>>>>> I'll create a review request unless anyone has an objection.
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>> Alex Ough
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
> > shadowsor@gmail.com
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> I have done parallel KVM migrations without issue, it's "supposed
> > to
> > >>>>>>>> work". Really I think it's in the same boat as parallel
> > start/stop.
> > >>>>> It
> > >>>>>>>> should work, but the config option is there just in case. I think
> > we
> > >>>>>>>> should add it.
> > >>>>>>>>
> > >>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> > >>>>>>>> <ch...@sungard.com> wrote:
> > >>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> > >>>>>>>>>> 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
> > >>>>>>>>>
> > >>>>>>>>> In the case of VMware, the migrate command is executed via the
> > >>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
> > >>>>>>>>>
> > >>>>>
> > vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> > >>>>>>>>>
> > >>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
> > >>>>>>>>> requests for migrations. Specifically, it will throttle the
> > >>>>> migrations
> > >>>>>>>>> happening, based on it's internal concurrency constraints, but
> > the
> > >>>>> task
> > >>>>>>>>> queue will still accept more connections. Obviously the risk are
> > >>>>> the
> > >>>>>>>>> VMware layer tasks timing out if it takes too long for the task
> > >>>>> queue to
> > >>>>>>>>> complete.
> > >>>>>>>>>
> > >>>>>>>>> As for XenServer, it's happening in what appears to be a similar
> > >>>>> way
> > >>>>>>>>> (although the source host is the target for the migration API
> > >>>>> call).
> > >>>>>>>>>
> > >>>>>>>>> Check
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>
> > plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> > >>>>>>>>>
> > >>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
> > >>>>>>>>> migrations. Any experts know the answer to if it can handle
> > >>>>> concurrency
> > >>>>>>>>> in a stable way?
> > >>>>>>>>>
> > >>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
> > >>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
> > >>>>> operations.
> > >>>>>>>>>
> > >>>>>>>>> So do the HV experts on the list have any opinions about
> > XenServer
> > >>>>> and
> > >>>>>>>>> KVM migration concurrency?
> > >>>>>>>>>
> > >>>>>>>>> -chip
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >
> > > --
> > > Prasanna.,
> > >
> > > ------------------------
> > > Powered by BigRock.com
> > >
> >
> >
> >
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
Thank Koushik, and I modified what you pointed out (for 'MigrateCommand'
text) and updated the diffs.
Let me know if there is anything missing/incorrect.
Thanks
Alex Ough
On Tue, Dec 3, 2013 at 2:46 AM, Koushik Das <ko...@citrix.com> wrote:
> I have posted my review comments. Except for a few minor comments changes
> look good to me.
>
> -Koushik
>
> On 02-Dec-2013, at 9:15 PM, Alex Ough <al...@sungard.com> wrote:
>
> > All,
> >
> > It's been a while since this review was requested, so can anyone review
> > this to move on?
> >
> > Thanks in advance.
> > Alex Ough
> >
> >
> > On Fri, Nov 22, 2013 at 11:51 AM, Alex Ough <al...@sungard.com>
> wrote:
> >
> >> Thanks to help from many developers,
> >> I sent my first review request in the cloudstack,
> >> https://reviews.apache.org/r/15763/,
> >> so please take a look at it and let me know if there is anything
> >> missing/incorrect.
> >>
> >> Thanks again.
> >> Alex Ough
> >>
> >>
> >> On Thu, Nov 21, 2013 at 10:09 AM, Alex Ough <al...@sungard.com>
> wrote:
> >>
> >>> Hi Wido,
> >>>
> >>> Related with the 'disk_offering.cache_mode',
> >>> I found that there is a sql file to add that column, which is
> 'cloudstack/
> >>> developer/target/db/db/schema-430to440.sql'.
> >>> But after running it manually, I have another error saying that the
> >>> 'cache_mode' cannot be null, so I just changed the column to allow
> null to
> >>> move on.
> >>>
> >>> So you may include the sql file and allow null in that column.
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Wed, Nov 20, 2013 at 3:45 PM, Alex Huang <Alex.Huang@citrix.com
> >wrote:
> >>>
> >>>> Wido,
> >>>>
> >>>>
> >>>>
> >>>> Looks like you didn’t update your schema file or forgot to add a
> schema
> >>>> upgrade file in master? See the error described by Alex below.
> >>>>
> >>>>
> >>>>
> >>>> @Alex
> >>>>
> >>>> You can probably remove the cachemode field in the DiskOfferingVO for
> now. Or revert 1edaa36 on your local repo to keep moving forward.
> >>>>
> >>>>
> >>>>
> >>>> --Alex
> >>>>
> >>>>
> >>>>
> >>>> *From:* Alex Ough [mailto:alex.ough@sungard.com]
> >>>> *Sent:* Wednesday, November 20, 2013 9:56 AM
> >>>> *To:* Alex Huang
> >>>> *Cc:* dev@cloudstack.apache.org
> >>>>
> >>>> *Subject:* Re: A question on vm migrations when hosts are set into a
> >>>> maintenance mode.
> >>>>
> >>>>
> >>>>
> >>>> Hi Alex,
> >>>>
> >>>>
> >>>>
> >>>> It looks like you moved the 'ExecuteInSequence' to the vm level from
> the
> >>>> management server, which seems to be ok, but at this time I cannot
> test it
> >>>>
> >>>> because when I try to start up the management server, it fails because
> >>>> of database schema error, which is 'Unknown column
> >>>> 'disk_offering.cache_mode' in 'field list' even if I re-built the
> database.
> >>>>
> >>>>
> >>>>
> >>>> Is the schema change part of your changes or something other developer
> >>>> changed?
> >>>>
> >>>>
> >>>>
> >>>> If that is from any other developer, can you fix this?
> >>>>
> >>>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> Alex Ough
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com>
> >>>> wrote:
> >>>>
> >>>> Alex,
> >>>>
> >>>>
> >>>>
> >>>> Can you do a pull from master and see if my fix fits your needs.
> >>>> Unfortunately, I’m on the road and couldn’t do an actual test of it.
> >>>>
> >>>>
> >>>>
> >>>> --Alex
> >>>>
> >>>>
> >>>>
> >>>> *From:* Alex Huang
> >>>> *Sent:* Tuesday, November 19, 2013 4:45 AM
> >>>> *To:* 'Alex Ough'; dev@cloudstack.apache.org
> >>>> *Subject:* RE: A question on vm migrations when hosts are set into a
> >>>> maintenance mode.
> >>>>
> >>>>
> >>>>
> >>>> Alex,
> >>>>
> >>>>
> >>>>
> >>>> Sorry for the late reply. Been travelling the last couple of weeks.
> >>>> I’ll look into this today.
> >>>>
> >>>>
> >>>>
> >>>> --Alex
> >>>>
> >>>>
> >>>>
> >>>> *From:* Alex Ough [mailto:alex.ough@sungard.com <
> alex.ough@sungard.com>]
> >>>>
> >>>> *Sent:* Monday, November 18, 2013 6:17 AM
> >>>> *To:* dev@cloudstack.apache.org
> >>>> *Cc:* Alex Huang
> >>>> *Subject:* Re: A question on vm migrations when hosts are set into a
> >>>> maintenance mode.
> >>>>
> >>>>
> >>>>
> >>>> Thank Parasanna & Sebastien,
> >>>>
> >>>> I also got his email and sent an email.
> >>>>
> >>>> Waiting for his reply...
> >>>>
> >>>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> Alex Ough
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <runseb@gmail.com
> >
> >>>> wrote:
> >>>>
> >>>> cc Alex Huang to get his attention:
> >>>>
> >>>>
> >>>>
> >>>> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org>
> wrote:
> >>>>
> >>>>> Alex, Could you just do a git blame on the file and copy the emails
> of
> >>>>> people who changed that bit of code? They may be able to help if
> Cc-ed
> >>>>> directly.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> >>>>>> I hate to sending the same emails over and over again, but I really
> >>>> need to
> >>>>>> finalize this feature to be included in the next code freeze because
> >>>> this
> >>>>>> feature is very critical in our inside project.
> >>>>>>
> >>>>>> Anyone who can help, please?
> >>>>>> Thanks
> >>>>>> Alex Ough
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Not sure if Alex Huang checked this, but can anyone help to resolve
> >>>> this?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Alex Ough
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <alex.ough@sungard.com
> >
> >>>> wrote:
> >>>>>>>
> >>>>>>>> It sounds a little scary...
> >>>>>>>>
> >>>>>>>> I looked at the history and found these.
> >>>>>>>>
> >>>>>>>> 8/9/ : file moved to engine by Alex Huang
> >>>>>>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> >>>>>>>> 'getExecuteInSequence()' by Alex Huang
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi Alex Huang,
> >>>>>>>> I'm not sure if you're aware of this, but can you check this for
> me?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Alex Ough
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
> >>>> shadowsor@gmail.com>wrote:
> >>>>>>>>
> >>>>>>>>> I'm not sure. I know in the past when I've seen files change
> >>>> locations
> >>>>>>>>> it has also clobbered updates to that file. Someone branched, did
> >>>> the
> >>>>>>>>> reorganization work, and merged, while in-between the original
> file
> >>>>>>>>> changed.
> >>>>>>>>>
> >>>>>>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <
> alex.ough@sungard.com>
> >>>>>>>>> wrote:
> >>>>>>>>>> All,
> >>>>>>>>>>
> >>>>>>>>>> While merging my changes to 4.3 branch, I found that the option,
> >>>>>>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
> >>>>>>>>> Start/Stop/Copy
> >>>>>>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> *StopCommand stop = new StopCommand(vm,
> getExecuteInSequence());*
> >>>>>>>>>>
> >>>>>>>>>> *protected boolean getExecuteInSequence() {*
> >>>>>>>>>> * return false;*
> >>>>>>>>>> *}*
> >>>>>>>>>>
> >>>>>>>>>> As you see in the above, the function, 'getExecuteInSequence',
> >>>> just
> >>>>>>>>> returns
> >>>>>>>>>> false instead of getting the value from the global variable.
> >>>>>>>>>>
> >>>>>>>>>> And one more change is that the file has been moved to
> >>>>>>>>>> 'engine/orchestration/src/com/cloud/vm' from
> >>>> 'server/src/com/cloud/vm'.
> >>>>>>>>>>
> >>>>>>>>>> Am I missing something related with this or do we stop
> supporting
> >>>> this
> >>>>>>>>>> option in 4.3?
> >>>>>>>>>> I'm a little confused, so please help me resolve this.
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>>> Alex Ough
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <
> alex.ough@sungard.com
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Thanks a lot for your confirmation, Marcus.
> >>>>>>>>>>> I'll create a review request unless anyone has an objection.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks
> >>>>>>>>>>> Alex Ough
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
> >>>> shadowsor@gmail.com
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I have done parallel KVM migrations without issue, it's
> >>>> "supposed to
> >>>>>>>>>>>> work". Really I think it's in the same boat as parallel
> >>>> start/stop.
> >>>>>>>>> It
> >>>>>>>>>>>> should work, but the config option is there just in case. I
> >>>> think we
> >>>>>>>>>>>> should add it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>>>>>>>>>>> <ch...@sungard.com> wrote:
> >>>>>>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In the case of VMware, the migrate command is executed via
> the
> >>>>>>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
> >>>>>>>>>>>>>
> >>>>>>>>>
> >>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For VMware, I know that vCenter will queue and process
> >>>> concurrent
> >>>>>>>>>>>>> requests for migrations. Specifically, it will throttle the
> >>>>>>>>> migrations
> >>>>>>>>>>>>> happening, based on it's internal concurrency constraints,
> but
> >>>> the
> >>>>>>>>> task
> >>>>>>>>>>>>> queue will still accept more connections. Obviously the risk
> >>>> are
> >>>>>>>>> the
> >>>>>>>>>>>>> VMware layer tasks timing out if it takes too long for the
> task
> >>>>>>>>> queue to
> >>>>>>>>>>>>> complete.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> As for XenServer, it's happening in what appears to be a
> >>>> similar
> >>>>>>>>> way
> >>>>>>>>>>>>> (although the source host is the target for the migration API
> >>>>>>>>> call).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Check
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>
> >>>>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I'm not familiar enough with XenServer's concurrency model
> for
> >>>>>>>>>>>>> migrations. Any experts know the answer to if it can handle
> >>>>>>>>> concurrency
> >>>>>>>>>>>>> in a stable way?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> With KVM, it's obviously executing via the agent. Similarly
> to
> >>>>>>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
> >>>>>>>>> operations.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> So do the HV experts on the list have any opinions about
> >>>> XenServer
> >>>>>>>>> and
> >>>>>>>>>>>>> KVM migration concurrency?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -chip
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Prasanna.,
> >>>>>
> >>>>> ------------------------
> >>>>> Powered by BigRock.com
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
>
>
>
Re: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Koushik Das <ko...@citrix.com>.
I have posted my review comments. Except for a few minor comments changes look good to me.
-Koushik
On 02-Dec-2013, at 9:15 PM, Alex Ough <al...@sungard.com> wrote:
> All,
>
> It's been a while since this review was requested, so can anyone review
> this to move on?
>
> Thanks in advance.
> Alex Ough
>
>
> On Fri, Nov 22, 2013 at 11:51 AM, Alex Ough <al...@sungard.com> wrote:
>
>> Thanks to help from many developers,
>> I sent my first review request in the cloudstack,
>> https://reviews.apache.org/r/15763/,
>> so please take a look at it and let me know if there is anything
>> missing/incorrect.
>>
>> Thanks again.
>> Alex Ough
>>
>>
>> On Thu, Nov 21, 2013 at 10:09 AM, Alex Ough <al...@sungard.com> wrote:
>>
>>> Hi Wido,
>>>
>>> Related with the 'disk_offering.cache_mode',
>>> I found that there is a sql file to add that column, which is 'cloudstack/
>>> developer/target/db/db/schema-430to440.sql'.
>>> But after running it manually, I have another error saying that the
>>> 'cache_mode' cannot be null, so I just changed the column to allow null to
>>> move on.
>>>
>>> So you may include the sql file and allow null in that column.
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Nov 20, 2013 at 3:45 PM, Alex Huang <Al...@citrix.com>wrote:
>>>
>>>> Wido,
>>>>
>>>>
>>>>
>>>> Looks like you didn’t update your schema file or forgot to add a schema
>>>> upgrade file in master? See the error described by Alex below.
>>>>
>>>>
>>>>
>>>> @Alex
>>>>
>>>> You can probably remove the cachemode field in the DiskOfferingVO for now. Or revert 1edaa36 on your local repo to keep moving forward.
>>>>
>>>>
>>>>
>>>> --Alex
>>>>
>>>>
>>>>
>>>> *From:* Alex Ough [mailto:alex.ough@sungard.com]
>>>> *Sent:* Wednesday, November 20, 2013 9:56 AM
>>>> *To:* Alex Huang
>>>> *Cc:* dev@cloudstack.apache.org
>>>>
>>>> *Subject:* Re: A question on vm migrations when hosts are set into a
>>>> maintenance mode.
>>>>
>>>>
>>>>
>>>> Hi Alex,
>>>>
>>>>
>>>>
>>>> It looks like you moved the 'ExecuteInSequence' to the vm level from the
>>>> management server, which seems to be ok, but at this time I cannot test it
>>>>
>>>> because when I try to start up the management server, it fails because
>>>> of database schema error, which is 'Unknown column
>>>> 'disk_offering.cache_mode' in 'field list' even if I re-built the database.
>>>>
>>>>
>>>>
>>>> Is the schema change part of your changes or something other developer
>>>> changed?
>>>>
>>>>
>>>>
>>>> If that is from any other developer, can you fix this?
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Alex Ough
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com>
>>>> wrote:
>>>>
>>>> Alex,
>>>>
>>>>
>>>>
>>>> Can you do a pull from master and see if my fix fits your needs.
>>>> Unfortunately, I’m on the road and couldn’t do an actual test of it.
>>>>
>>>>
>>>>
>>>> --Alex
>>>>
>>>>
>>>>
>>>> *From:* Alex Huang
>>>> *Sent:* Tuesday, November 19, 2013 4:45 AM
>>>> *To:* 'Alex Ough'; dev@cloudstack.apache.org
>>>> *Subject:* RE: A question on vm migrations when hosts are set into a
>>>> maintenance mode.
>>>>
>>>>
>>>>
>>>> Alex,
>>>>
>>>>
>>>>
>>>> Sorry for the late reply. Been travelling the last couple of weeks.
>>>> I’ll look into this today.
>>>>
>>>>
>>>>
>>>> --Alex
>>>>
>>>>
>>>>
>>>> *From:* Alex Ough [mailto:alex.ough@sungard.com <al...@sungard.com>]
>>>>
>>>> *Sent:* Monday, November 18, 2013 6:17 AM
>>>> *To:* dev@cloudstack.apache.org
>>>> *Cc:* Alex Huang
>>>> *Subject:* Re: A question on vm migrations when hosts are set into a
>>>> maintenance mode.
>>>>
>>>>
>>>>
>>>> Thank Parasanna & Sebastien,
>>>>
>>>> I also got his email and sent an email.
>>>>
>>>> Waiting for his reply...
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Alex Ough
>>>>
>>>>
>>>>
>>>> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>
>>>> cc Alex Huang to get his attention:
>>>>
>>>>
>>>>
>>>> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
>>>>
>>>>> Alex, Could you just do a git blame on the file and copy the emails of
>>>>> people who changed that bit of code? They may be able to help if Cc-ed
>>>>> directly.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>>>>>> I hate to sending the same emails over and over again, but I really
>>>> need to
>>>>>> finalize this feature to be included in the next code freeze because
>>>> this
>>>>>> feature is very critical in our inside project.
>>>>>>
>>>>>> Anyone who can help, please?
>>>>>> Thanks
>>>>>> Alex Ough
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
>>>> wrote:
>>>>>>
>>>>>>> Not sure if Alex Huang checked this, but can anyone help to resolve
>>>> this?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Alex Ough
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
>>>> wrote:
>>>>>>>
>>>>>>>> It sounds a little scary...
>>>>>>>>
>>>>>>>> I looked at the history and found these.
>>>>>>>>
>>>>>>>> 8/9/ : file moved to engine by Alex Huang
>>>>>>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>>>>>>>> 'getExecuteInSequence()' by Alex Huang
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Alex Huang,
>>>>>>>> I'm not sure if you're aware of this, but can you check this for me?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Alex Ough
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
>>>> shadowsor@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> I'm not sure. I know in the past when I've seen files change
>>>> locations
>>>>>>>>> it has also clobbered updates to that file. Someone branched, did
>>>> the
>>>>>>>>> reorganization work, and merged, while in-between the original file
>>>>>>>>> changed.
>>>>>>>>>
>>>>>>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
>>>>>>>>> wrote:
>>>>>>>>>> All,
>>>>>>>>>>
>>>>>>>>>> While merging my changes to 4.3 branch, I found that the option,
>>>>>>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>>>>>>>>> Start/Stop/Copy
>>>>>>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>>>>>>>>>
>>>>>>>>>> *protected boolean getExecuteInSequence() {*
>>>>>>>>>> * return false;*
>>>>>>>>>> *}*
>>>>>>>>>>
>>>>>>>>>> As you see in the above, the function, 'getExecuteInSequence',
>>>> just
>>>>>>>>> returns
>>>>>>>>>> false instead of getting the value from the global variable.
>>>>>>>>>>
>>>>>>>>>> And one more change is that the file has been moved to
>>>>>>>>>> 'engine/orchestration/src/com/cloud/vm' from
>>>> 'server/src/com/cloud/vm'.
>>>>>>>>>>
>>>>>>>>>> Am I missing something related with this or do we stop supporting
>>>> this
>>>>>>>>>> option in 4.3?
>>>>>>>>>> I'm a little confused, so please help me resolve this.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Alex Ough
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <alex.ough@sungard.com
>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks a lot for your confirmation, Marcus.
>>>>>>>>>>> I'll create a review request unless anyone has an objection.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Alex Ough
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
>>>> shadowsor@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I have done parallel KVM migrations without issue, it's
>>>> "supposed to
>>>>>>>>>>>> work". Really I think it's in the same boat as parallel
>>>> start/stop.
>>>>>>>>> It
>>>>>>>>>>>> should work, but the config option is there just in case. I
>>>> think we
>>>>>>>>>>>> should add it.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>>>>>>>>>>> <ch...@sungard.com> wrote:
>>>>>>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>> In the case of VMware, the migrate command is executed via the
>>>>>>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>>>>>>>>>>>>>
>>>>>>>>>
>>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>>>>>>>>>>>>
>>>>>>>>>>>>> For VMware, I know that vCenter will queue and process
>>>> concurrent
>>>>>>>>>>>>> requests for migrations. Specifically, it will throttle the
>>>>>>>>> migrations
>>>>>>>>>>>>> happening, based on it's internal concurrency constraints, but
>>>> the
>>>>>>>>> task
>>>>>>>>>>>>> queue will still accept more connections. Obviously the risk
>>>> are
>>>>>>>>> the
>>>>>>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>>>>>>>>> queue to
>>>>>>>>>>>>> complete.
>>>>>>>>>>>>>
>>>>>>>>>>>>> As for XenServer, it's happening in what appears to be a
>>>> similar
>>>>>>>>> way
>>>>>>>>>>>>> (although the source host is the target for the migration API
>>>>>>>>> call).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Check
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>>>>>>>>>>>>> migrations. Any experts know the answer to if it can handle
>>>>>>>>> concurrency
>>>>>>>>>>>>> in a stable way?
>>>>>>>>>>>>>
>>>>>>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>>>>>>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>>>>>>>>> operations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So do the HV experts on the list have any opinions about
>>>> XenServer
>>>>>>>>> and
>>>>>>>>>>>>> KVM migration concurrency?
>>>>>>>>>>>>>
>>>>>>>>>>>>> -chip
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> Prasanna.,
>>>>>
>>>>> ------------------------
>>>>> Powered by BigRock.com
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
All,
It's been a while since this review was requested, so can anyone review
this to move on?
Thanks in advance.
Alex Ough
On Fri, Nov 22, 2013 at 11:51 AM, Alex Ough <al...@sungard.com> wrote:
> Thanks to help from many developers,
> I sent my first review request in the cloudstack,
> https://reviews.apache.org/r/15763/,
> so please take a look at it and let me know if there is anything
> missing/incorrect.
>
> Thanks again.
> Alex Ough
>
>
> On Thu, Nov 21, 2013 at 10:09 AM, Alex Ough <al...@sungard.com> wrote:
>
>> Hi Wido,
>>
>> Related with the 'disk_offering.cache_mode',
>> I found that there is a sql file to add that column, which is 'cloudstack/
>> developer/target/db/db/schema-430to440.sql'.
>> But after running it manually, I have another error saying that the
>> 'cache_mode' cannot be null, so I just changed the column to allow null to
>> move on.
>>
>> So you may include the sql file and allow null in that column.
>>
>> Thanks
>> Alex Ough
>>
>>
>> On Wed, Nov 20, 2013 at 3:45 PM, Alex Huang <Al...@citrix.com>wrote:
>>
>>> Wido,
>>>
>>>
>>>
>>> Looks like you didn’t update your schema file or forgot to add a schema
>>> upgrade file in master? See the error described by Alex below.
>>>
>>>
>>>
>>> @Alex
>>>
>>> You can probably remove the cachemode field in the DiskOfferingVO for now. Or revert 1edaa36 on your local repo to keep moving forward.
>>>
>>>
>>>
>>> --Alex
>>>
>>>
>>>
>>> *From:* Alex Ough [mailto:alex.ough@sungard.com]
>>> *Sent:* Wednesday, November 20, 2013 9:56 AM
>>> *To:* Alex Huang
>>> *Cc:* dev@cloudstack.apache.org
>>>
>>> *Subject:* Re: A question on vm migrations when hosts are set into a
>>> maintenance mode.
>>>
>>>
>>>
>>> Hi Alex,
>>>
>>>
>>>
>>> It looks like you moved the 'ExecuteInSequence' to the vm level from the
>>> management server, which seems to be ok, but at this time I cannot test it
>>>
>>> because when I try to start up the management server, it fails because
>>> of database schema error, which is 'Unknown column
>>> 'disk_offering.cache_mode' in 'field list' even if I re-built the database.
>>>
>>>
>>>
>>> Is the schema change part of your changes or something other developer
>>> changed?
>>>
>>>
>>>
>>> If that is from any other developer, can you fix this?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Alex Ough
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com>
>>> wrote:
>>>
>>> Alex,
>>>
>>>
>>>
>>> Can you do a pull from master and see if my fix fits your needs.
>>> Unfortunately, I’m on the road and couldn’t do an actual test of it.
>>>
>>>
>>>
>>> --Alex
>>>
>>>
>>>
>>> *From:* Alex Huang
>>> *Sent:* Tuesday, November 19, 2013 4:45 AM
>>> *To:* 'Alex Ough'; dev@cloudstack.apache.org
>>> *Subject:* RE: A question on vm migrations when hosts are set into a
>>> maintenance mode.
>>>
>>>
>>>
>>> Alex,
>>>
>>>
>>>
>>> Sorry for the late reply. Been travelling the last couple of weeks.
>>> I’ll look into this today.
>>>
>>>
>>>
>>> --Alex
>>>
>>>
>>>
>>> *From:* Alex Ough [mailto:alex.ough@sungard.com <al...@sungard.com>]
>>>
>>> *Sent:* Monday, November 18, 2013 6:17 AM
>>> *To:* dev@cloudstack.apache.org
>>> *Cc:* Alex Huang
>>> *Subject:* Re: A question on vm migrations when hosts are set into a
>>> maintenance mode.
>>>
>>>
>>>
>>> Thank Parasanna & Sebastien,
>>>
>>> I also got his email and sent an email.
>>>
>>> Waiting for his reply...
>>>
>>>
>>>
>>> Thanks
>>>
>>> Alex Ough
>>>
>>>
>>>
>>> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>
>>> cc Alex Huang to get his attention:
>>>
>>>
>>>
>>> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
>>>
>>> > Alex, Could you just do a git blame on the file and copy the emails of
>>> > people who changed that bit of code? They may be able to help if Cc-ed
>>> > directly.
>>> >
>>> > Thanks,
>>> >
>>> > On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>>> >> I hate to sending the same emails over and over again, but I really
>>> need to
>>> >> finalize this feature to be included in the next code freeze because
>>> this
>>> >> feature is very critical in our inside project.
>>> >>
>>> >> Anyone who can help, please?
>>> >> Thanks
>>> >> Alex Ough
>>> >>
>>> >>
>>> >> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
>>> wrote:
>>> >>
>>> >>> Not sure if Alex Huang checked this, but can anyone help to resolve
>>> this?
>>> >>>
>>> >>> Thanks
>>> >>> Alex Ough
>>> >>>
>>> >>>
>>> >>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
>>> wrote:
>>> >>>
>>> >>>> It sounds a little scary...
>>> >>>>
>>> >>>> I looked at the history and found these.
>>> >>>>
>>> >>>> 8/9/ : file moved to engine by Alex Huang
>>> >>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>>> >>>> 'getExecuteInSequence()' by Alex Huang
>>> >>>>
>>> >>>>
>>> >>>> Hi Alex Huang,
>>> >>>> I'm not sure if you're aware of this, but can you check this for me?
>>> >>>>
>>> >>>> Thanks
>>> >>>> Alex Ough
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
>>> shadowsor@gmail.com>wrote:
>>> >>>>
>>> >>>>> I'm not sure. I know in the past when I've seen files change
>>> locations
>>> >>>>> it has also clobbered updates to that file. Someone branched, did
>>> the
>>> >>>>> reorganization work, and merged, while in-between the original file
>>> >>>>> changed.
>>> >>>>>
>>> >>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
>>> >>>>> wrote:
>>> >>>>>> All,
>>> >>>>>>
>>> >>>>>> While merging my changes to 4.3 branch, I found that the option,
>>> >>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>>> >>>>> Start/Stop/Copy
>>> >>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>> >>>>>>
>>> >>>>>> *protected boolean getExecuteInSequence() {*
>>> >>>>>> * return false;*
>>> >>>>>> *}*
>>> >>>>>>
>>> >>>>>> As you see in the above, the function, 'getExecuteInSequence',
>>> just
>>> >>>>> returns
>>> >>>>>> false instead of getting the value from the global variable.
>>> >>>>>>
>>> >>>>>> And one more change is that the file has been moved to
>>> >>>>>> 'engine/orchestration/src/com/cloud/vm' from
>>> 'server/src/com/cloud/vm'.
>>> >>>>>>
>>> >>>>>> Am I missing something related with this or do we stop supporting
>>> this
>>> >>>>>> option in 4.3?
>>> >>>>>> I'm a little confused, so please help me resolve this.
>>> >>>>>>
>>> >>>>>> Thanks
>>> >>>>>> Alex Ough
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <alex.ough@sungard.com
>>> >
>>> >>>>> wrote:
>>> >>>>>>
>>> >>>>>>> Thanks a lot for your confirmation, Marcus.
>>> >>>>>>> I'll create a review request unless anyone has an objection.
>>> >>>>>>>
>>> >>>>>>> Thanks
>>> >>>>>>> Alex Ough
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
>>> shadowsor@gmail.com
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>>> I have done parallel KVM migrations without issue, it's
>>> "supposed to
>>> >>>>>>>> work". Really I think it's in the same boat as parallel
>>> start/stop.
>>> >>>>> It
>>> >>>>>>>> should work, but the config option is there just in case. I
>>> think we
>>> >>>>>>>> should add it.
>>> >>>>>>>>
>>> >>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>> >>>>>>>> <ch...@sungard.com> wrote:
>>> >>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>> >>>>>>>>>> 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
>>> >>>>>>>>>
>>> >>>>>>>>> In the case of VMware, the migrate command is executed via the
>>> >>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>>> >>>>>>>>>
>>> >>>>>
>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>> >>>>>>>>>
>>> >>>>>>>>> For VMware, I know that vCenter will queue and process
>>> concurrent
>>> >>>>>>>>> requests for migrations. Specifically, it will throttle the
>>> >>>>> migrations
>>> >>>>>>>>> happening, based on it's internal concurrency constraints, but
>>> the
>>> >>>>> task
>>> >>>>>>>>> queue will still accept more connections. Obviously the risk
>>> are
>>> >>>>> the
>>> >>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>>> >>>>> queue to
>>> >>>>>>>>> complete.
>>> >>>>>>>>>
>>> >>>>>>>>> As for XenServer, it's happening in what appears to be a
>>> similar
>>> >>>>> way
>>> >>>>>>>>> (although the source host is the target for the migration API
>>> >>>>> call).
>>> >>>>>>>>>
>>> >>>>>>>>> Check
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>
>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>> >>>>>>>>>
>>> >>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>>> >>>>>>>>> migrations. Any experts know the answer to if it can handle
>>> >>>>> concurrency
>>> >>>>>>>>> in a stable way?
>>> >>>>>>>>>
>>> >>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>>> >>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>>> >>>>> operations.
>>> >>>>>>>>>
>>> >>>>>>>>> So do the HV experts on the list have any opinions about
>>> XenServer
>>> >>>>> and
>>> >>>>>>>>> KVM migration concurrency?
>>> >>>>>>>>>
>>> >>>>>>>>> -chip
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>
>>> >
>>> > --
>>> > Prasanna.,
>>> >
>>> > ------------------------
>>> > Powered by BigRock.com
>>> >
>>>
>>>
>>>
>>>
>>>
>>
>>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
Thanks to help from many developers,
I sent my first review request in the cloudstack,
https://reviews.apache.org/r/15763/,
so please take a look at it and let me know if there is anything
missing/incorrect.
Thanks again.
Alex Ough
On Thu, Nov 21, 2013 at 10:09 AM, Alex Ough <al...@sungard.com> wrote:
> Hi Wido,
>
> Related with the 'disk_offering.cache_mode',
> I found that there is a sql file to add that column, which is 'cloudstack/
> developer/target/db/db/schema-430to440.sql'.
> But after running it manually, I have another error saying that the
> 'cache_mode' cannot be null, so I just changed the column to allow null to
> move on.
>
> So you may include the sql file and allow null in that column.
>
> Thanks
> Alex Ough
>
>
> On Wed, Nov 20, 2013 at 3:45 PM, Alex Huang <Al...@citrix.com> wrote:
>
>> Wido,
>>
>>
>>
>> Looks like you didn’t update your schema file or forgot to add a schema
>> upgrade file in master? See the error described by Alex below.
>>
>>
>>
>> @Alex
>>
>> You can probably remove the cachemode field in the DiskOfferingVO for now. Or revert 1edaa36 on your local repo to keep moving forward.
>>
>>
>>
>> --Alex
>>
>>
>>
>> *From:* Alex Ough [mailto:alex.ough@sungard.com]
>> *Sent:* Wednesday, November 20, 2013 9:56 AM
>> *To:* Alex Huang
>> *Cc:* dev@cloudstack.apache.org
>>
>> *Subject:* Re: A question on vm migrations when hosts are set into a
>> maintenance mode.
>>
>>
>>
>> Hi Alex,
>>
>>
>>
>> It looks like you moved the 'ExecuteInSequence' to the vm level from the
>> management server, which seems to be ok, but at this time I cannot test it
>>
>> because when I try to start up the management server, it fails because of
>> database schema error, which is 'Unknown column 'disk_offering.cache_mode'
>> in 'field list' even if I re-built the database.
>>
>>
>>
>> Is the schema change part of your changes or something other developer
>> changed?
>>
>>
>>
>> If that is from any other developer, can you fix this?
>>
>>
>>
>> Thanks
>>
>> Alex Ough
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com>
>> wrote:
>>
>> Alex,
>>
>>
>>
>> Can you do a pull from master and see if my fix fits your needs.
>> Unfortunately, I’m on the road and couldn’t do an actual test of it.
>>
>>
>>
>> --Alex
>>
>>
>>
>> *From:* Alex Huang
>> *Sent:* Tuesday, November 19, 2013 4:45 AM
>> *To:* 'Alex Ough'; dev@cloudstack.apache.org
>> *Subject:* RE: A question on vm migrations when hosts are set into a
>> maintenance mode.
>>
>>
>>
>> Alex,
>>
>>
>>
>> Sorry for the late reply. Been travelling the last couple of weeks.
>> I’ll look into this today.
>>
>>
>>
>> --Alex
>>
>>
>>
>> *From:* Alex Ough [mailto:alex.ough@sungard.com <al...@sungard.com>]
>> *Sent:* Monday, November 18, 2013 6:17 AM
>> *To:* dev@cloudstack.apache.org
>> *Cc:* Alex Huang
>> *Subject:* Re: A question on vm migrations when hosts are set into a
>> maintenance mode.
>>
>>
>>
>> Thank Parasanna & Sebastien,
>>
>> I also got his email and sent an email.
>>
>> Waiting for his reply...
>>
>>
>>
>> Thanks
>>
>> Alex Ough
>>
>>
>>
>> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>
>> cc Alex Huang to get his attention:
>>
>>
>>
>> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
>>
>> > Alex, Could you just do a git blame on the file and copy the emails of
>> > people who changed that bit of code? They may be able to help if Cc-ed
>> > directly.
>> >
>> > Thanks,
>> >
>> > On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>> >> I hate to sending the same emails over and over again, but I really
>> need to
>> >> finalize this feature to be included in the next code freeze because
>> this
>> >> feature is very critical in our inside project.
>> >>
>> >> Anyone who can help, please?
>> >> Thanks
>> >> Alex Ough
>> >>
>> >>
>> >> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
>> wrote:
>> >>
>> >>> Not sure if Alex Huang checked this, but can anyone help to resolve
>> this?
>> >>>
>> >>> Thanks
>> >>> Alex Ough
>> >>>
>> >>>
>> >>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
>> wrote:
>> >>>
>> >>>> It sounds a little scary...
>> >>>>
>> >>>> I looked at the history and found these.
>> >>>>
>> >>>> 8/9/ : file moved to engine by Alex Huang
>> >>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>> >>>> 'getExecuteInSequence()' by Alex Huang
>> >>>>
>> >>>>
>> >>>> Hi Alex Huang,
>> >>>> I'm not sure if you're aware of this, but can you check this for me?
>> >>>>
>> >>>> Thanks
>> >>>> Alex Ough
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
>> shadowsor@gmail.com>wrote:
>> >>>>
>> >>>>> I'm not sure. I know in the past when I've seen files change
>> locations
>> >>>>> it has also clobbered updates to that file. Someone branched, did
>> the
>> >>>>> reorganization work, and merged, while in-between the original file
>> >>>>> changed.
>> >>>>>
>> >>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
>> >>>>> wrote:
>> >>>>>> All,
>> >>>>>>
>> >>>>>> While merging my changes to 4.3 branch, I found that the option,
>> >>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>> >>>>> Start/Stop/Copy
>> >>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>> >>>>>>
>> >>>>>>
>> >>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>> >>>>>>
>> >>>>>> *protected boolean getExecuteInSequence() {*
>> >>>>>> * return false;*
>> >>>>>> *}*
>> >>>>>>
>> >>>>>> As you see in the above, the function, 'getExecuteInSequence', just
>> >>>>> returns
>> >>>>>> false instead of getting the value from the global variable.
>> >>>>>>
>> >>>>>> And one more change is that the file has been moved to
>> >>>>>> 'engine/orchestration/src/com/cloud/vm' from
>> 'server/src/com/cloud/vm'.
>> >>>>>>
>> >>>>>> Am I missing something related with this or do we stop supporting
>> this
>> >>>>>> option in 4.3?
>> >>>>>> I'm a little confused, so please help me resolve this.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>> Alex Ough
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>> Thanks a lot for your confirmation, Marcus.
>> >>>>>>> I'll create a review request unless anyone has an objection.
>> >>>>>>>
>> >>>>>>> Thanks
>> >>>>>>> Alex Ough
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
>> shadowsor@gmail.com
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> I have done parallel KVM migrations without issue, it's
>> "supposed to
>> >>>>>>>> work". Really I think it's in the same boat as parallel
>> start/stop.
>> >>>>> It
>> >>>>>>>> should work, but the config option is there just in case. I
>> think we
>> >>>>>>>> should add it.
>> >>>>>>>>
>> >>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>> >>>>>>>> <ch...@sungard.com> wrote:
>> >>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>> >>>>>>>>>> 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
>> >>>>>>>>>
>> >>>>>>>>> In the case of VMware, the migrate command is executed via the
>> >>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>> >>>>>>>>>
>> >>>>>
>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>> >>>>>>>>>
>> >>>>>>>>> For VMware, I know that vCenter will queue and process
>> concurrent
>> >>>>>>>>> requests for migrations. Specifically, it will throttle the
>> >>>>> migrations
>> >>>>>>>>> happening, based on it's internal concurrency constraints, but
>> the
>> >>>>> task
>> >>>>>>>>> queue will still accept more connections. Obviously the risk
>> are
>> >>>>> the
>> >>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>> >>>>> queue to
>> >>>>>>>>> complete.
>> >>>>>>>>>
>> >>>>>>>>> As for XenServer, it's happening in what appears to be a similar
>> >>>>> way
>> >>>>>>>>> (although the source host is the target for the migration API
>> >>>>> call).
>> >>>>>>>>>
>> >>>>>>>>> Check
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>
>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>> >>>>>>>>>
>> >>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>> >>>>>>>>> migrations. Any experts know the answer to if it can handle
>> >>>>> concurrency
>> >>>>>>>>> in a stable way?
>> >>>>>>>>>
>> >>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>> >>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>> >>>>> operations.
>> >>>>>>>>>
>> >>>>>>>>> So do the HV experts on the list have any opinions about
>> XenServer
>> >>>>> and
>> >>>>>>>>> KVM migration concurrency?
>> >>>>>>>>>
>> >>>>>>>>> -chip
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >
>> > --
>> > Prasanna.,
>> >
>> > ------------------------
>> > Powered by BigRock.com
>> >
>>
>>
>>
>>
>>
>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
Hi Wido,
Related with the 'disk_offering.cache_mode',
I found that there is a sql file to add that column, which is 'cloudstack/
developer/target/db/db/schema-430to440.sql'.
But after running it manually, I have another error saying that the
'cache_mode' cannot be null, so I just changed the column to allow null to
move on.
So you may include the sql file and allow null in that column.
Thanks
Alex Ough
On Wed, Nov 20, 2013 at 3:45 PM, Alex Huang <Al...@citrix.com> wrote:
> Wido,
>
>
>
> Looks like you didn’t update your schema file or forgot to add a schema
> upgrade file in master? See the error described by Alex below.
>
>
>
> @Alex
>
> You can probably remove the cachemode field in the DiskOfferingVO for now. Or revert 1edaa36 on your local repo to keep moving forward.
>
>
>
> --Alex
>
>
>
> *From:* Alex Ough [mailto:alex.ough@sungard.com]
> *Sent:* Wednesday, November 20, 2013 9:56 AM
> *To:* Alex Huang
> *Cc:* dev@cloudstack.apache.org
>
> *Subject:* Re: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Hi Alex,
>
>
>
> It looks like you moved the 'ExecuteInSequence' to the vm level from the
> management server, which seems to be ok, but at this time I cannot test it
>
> because when I try to start up the management server, it fails because of
> database schema error, which is 'Unknown column 'disk_offering.cache_mode'
> in 'field list' even if I re-built the database.
>
>
>
> Is the schema change part of your changes or something other developer
> changed?
>
>
>
> If that is from any other developer, can you fix this?
>
>
>
> Thanks
>
> Alex Ough
>
>
>
>
>
>
>
> On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com> wrote:
>
> Alex,
>
>
>
> Can you do a pull from master and see if my fix fits your needs.
> Unfortunately, I’m on the road and couldn’t do an actual test of it.
>
>
>
> --Alex
>
>
>
> *From:* Alex Huang
> *Sent:* Tuesday, November 19, 2013 4:45 AM
> *To:* 'Alex Ough'; dev@cloudstack.apache.org
> *Subject:* RE: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Alex,
>
>
>
> Sorry for the late reply. Been travelling the last couple of weeks. I’ll
> look into this today.
>
>
>
> --Alex
>
>
>
> *From:* Alex Ough [mailto:alex.ough@sungard.com <al...@sungard.com>]
> *Sent:* Monday, November 18, 2013 6:17 AM
> *To:* dev@cloudstack.apache.org
> *Cc:* Alex Huang
> *Subject:* Re: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Thank Parasanna & Sebastien,
>
> I also got his email and sent an email.
>
> Waiting for his reply...
>
>
>
> Thanks
>
> Alex Ough
>
>
>
> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
>
> cc Alex Huang to get his attention:
>
>
>
> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
>
> > Alex, Could you just do a git blame on the file and copy the emails of
> > people who changed that bit of code? They may be able to help if Cc-ed
> > directly.
> >
> > Thanks,
> >
> > On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> >> I hate to sending the same emails over and over again, but I really
> need to
> >> finalize this feature to be included in the next code freeze because
> this
> >> feature is very critical in our inside project.
> >>
> >> Anyone who can help, please?
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
> wrote:
> >>
> >>> Not sure if Alex Huang checked this, but can anyone help to resolve
> this?
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
> wrote:
> >>>
> >>>> It sounds a little scary...
> >>>>
> >>>> I looked at the history and found these.
> >>>>
> >>>> 8/9/ : file moved to engine by Alex Huang
> >>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> >>>> 'getExecuteInSequence()' by Alex Huang
> >>>>
> >>>>
> >>>> Hi Alex Huang,
> >>>> I'm not sure if you're aware of this, but can you check this for me?
> >>>>
> >>>> Thanks
> >>>> Alex Ough
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
> shadowsor@gmail.com>wrote:
> >>>>
> >>>>> I'm not sure. I know in the past when I've seen files change
> locations
> >>>>> it has also clobbered updates to that file. Someone branched, did the
> >>>>> reorganization work, and merged, while in-between the original file
> >>>>> changed.
> >>>>>
> >>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>> All,
> >>>>>>
> >>>>>> While merging my changes to 4.3 branch, I found that the option,
> >>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
> >>>>> Start/Stop/Copy
> >>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
> >>>>>>
> >>>>>>
> >>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> >>>>>>
> >>>>>> *protected boolean getExecuteInSequence() {*
> >>>>>> * return false;*
> >>>>>> *}*
> >>>>>>
> >>>>>> As you see in the above, the function, 'getExecuteInSequence', just
> >>>>> returns
> >>>>>> false instead of getting the value from the global variable.
> >>>>>>
> >>>>>> And one more change is that the file has been moved to
> >>>>>> 'engine/orchestration/src/com/cloud/vm' from
> 'server/src/com/cloud/vm'.
> >>>>>>
> >>>>>> Am I missing something related with this or do we stop supporting
> this
> >>>>>> option in 4.3?
> >>>>>> I'm a little confused, so please help me resolve this.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Alex Ough
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Thanks a lot for your confirmation, Marcus.
> >>>>>>> I'll create a review request unless anyone has an objection.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Alex Ough
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
> shadowsor@gmail.com
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> I have done parallel KVM migrations without issue, it's "supposed
> to
> >>>>>>>> work". Really I think it's in the same boat as parallel
> start/stop.
> >>>>> It
> >>>>>>>> should work, but the config option is there just in case. I think
> we
> >>>>>>>> should add it.
> >>>>>>>>
> >>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>>>>>>> <ch...@sungard.com> wrote:
> >>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> In the case of VMware, the migrate command is executed via the
> >>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
> >>>>>>>>>
> >>>>>
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>>>>>>>>
> >>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
> >>>>>>>>> requests for migrations. Specifically, it will throttle the
> >>>>> migrations
> >>>>>>>>> happening, based on it's internal concurrency constraints, but
> the
> >>>>> task
> >>>>>>>>> queue will still accept more connections. Obviously the risk are
> >>>>> the
> >>>>>>>>> VMware layer tasks timing out if it takes too long for the task
> >>>>> queue to
> >>>>>>>>> complete.
> >>>>>>>>>
> >>>>>>>>> As for XenServer, it's happening in what appears to be a similar
> >>>>> way
> >>>>>>>>> (although the source host is the target for the migration API
> >>>>> call).
> >>>>>>>>>
> >>>>>>>>> Check
> >>>>>>>>>
> >>>>>>>>
> >>>>>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>>>>>>>>
> >>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
> >>>>>>>>> migrations. Any experts know the answer to if it can handle
> >>>>> concurrency
> >>>>>>>>> in a stable way?
> >>>>>>>>>
> >>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
> >>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
> >>>>> operations.
> >>>>>>>>>
> >>>>>>>>> So do the HV experts on the list have any opinions about
> XenServer
> >>>>> and
> >>>>>>>>> KVM migration concurrency?
> >>>>>>>>>
> >>>>>>>>> -chip
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > --
> > Prasanna.,
> >
> > ------------------------
> > Powered by BigRock.com
> >
>
>
>
>
>
RE: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Alex Huang <Al...@citrix.com>.
Wido,
Looks like you didn't update your schema file or forgot to add a schema upgrade file in master? See the error described by Alex below.
@Alex
You can probably remove the cachemode field in the DiskOfferingVO for now. Or revert 1edaa36 on your local repo to keep moving forward.
--Alex
From: Alex Ough [mailto:alex.ough@sungard.com]
Sent: Wednesday, November 20, 2013 9:56 AM
To: Alex Huang
Cc: dev@cloudstack.apache.org
Subject: Re: A question on vm migrations when hosts are set into a maintenance mode.
Hi Alex,
It looks like you moved the 'ExecuteInSequence' to the vm level from the management server, which seems to be ok, but at this time I cannot test it
because when I try to start up the management server, it fails because of database schema error, which is 'Unknown column 'disk_offering.cache_mode' in 'field list' even if I re-built the database.
Is the schema change part of your changes or something other developer changed?
If that is from any other developer, can you fix this?
Thanks
Alex Ough
On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com>> wrote:
Alex,
Can you do a pull from master and see if my fix fits your needs. Unfortunately, I'm on the road and couldn't do an actual test of it.
--Alex
From: Alex Huang
Sent: Tuesday, November 19, 2013 4:45 AM
To: 'Alex Ough'; dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Subject: RE: A question on vm migrations when hosts are set into a maintenance mode.
Alex,
Sorry for the late reply. Been travelling the last couple of weeks. I'll look into this today.
--Alex
From: Alex Ough [mailto:alex.ough@sungard.com]
Sent: Monday, November 18, 2013 6:17 AM
To: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Cc: Alex Huang
Subject: Re: A question on vm migrations when hosts are set into a maintenance mode.
Thank Parasanna & Sebastien,
I also got his email and sent an email.
Waiting for his reply...
Thanks
Alex Ough
On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>> wrote:
cc Alex Huang to get his attention:
On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org>> wrote:
> Alex, Could you just do a git blame on the file and copy the emails of
> people who changed that bit of code? They may be able to help if Cc-ed
> directly.
>
> Thanks,
>
> On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>> I hate to sending the same emails over and over again, but I really need to
>> finalize this feature to be included in the next code freeze because this
>> feature is very critical in our inside project.
>>
>> Anyone who can help, please?
>> Thanks
>> Alex Ough
>>
>>
>> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>> wrote:
>>
>>> Not sure if Alex Huang checked this, but can anyone help to resolve this?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>> wrote:
>>>
>>>> It sounds a little scary...
>>>>
>>>> I looked at the history and found these.
>>>>
>>>> 8/9/ : file moved to engine by Alex Huang
>>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>>>> 'getExecuteInSequence()' by Alex Huang
>>>>
>>>>
>>>> Hi Alex Huang,
>>>> I'm not sure if you're aware of this, but can you check this for me?
>>>>
>>>> Thanks
>>>> Alex Ough
>>>>
>>>>
>>>>
>>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>>wrote:
>>>>
>>>>> I'm not sure. I know in the past when I've seen files change locations
>>>>> it has also clobbered updates to that file. Someone branched, did the
>>>>> reorganization work, and merged, while in-between the original file
>>>>> changed.
>>>>>
>>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>> All,
>>>>>>
>>>>>> While merging my changes to 4.3 branch, I found that the option,
>>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>>>>> Start/Stop/Copy
>>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>>>>>>
>>>>>>
>>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>>>>>
>>>>>> *protected boolean getExecuteInSequence() {*
>>>>>> * return false;*
>>>>>> *}*
>>>>>>
>>>>>> As you see in the above, the function, 'getExecuteInSequence', just
>>>>> returns
>>>>>> false instead of getting the value from the global variable.
>>>>>>
>>>>>> And one more change is that the file has been moved to
>>>>>> 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>>>>>>
>>>>>> Am I missing something related with this or do we stop supporting this
>>>>>> option in 4.3?
>>>>>> I'm a little confused, so please help me resolve this.
>>>>>>
>>>>>> Thanks
>>>>>> Alex Ough
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>>
>>>>>>> Thanks a lot for your confirmation, Marcus.
>>>>>>> I'll create a review request unless anyone has an objection.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Alex Ough
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I have done parallel KVM migrations without issue, it's "supposed to
>>>>>>>> work". Really I think it's in the same boat as parallel start/stop.
>>>>> It
>>>>>>>> should work, but the config option is there just in case. I think we
>>>>>>>> should add it.
>>>>>>>>
>>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>>>>>>> <ch...@sungard.com>> wrote:
>>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> In the case of VMware, the migrate command is executed via the
>>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>>>>>>>>>
>>>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>>>>>>>>
>>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
>>>>>>>>> requests for migrations. Specifically, it will throttle the
>>>>> migrations
>>>>>>>>> happening, based on it's internal concurrency constraints, but the
>>>>> task
>>>>>>>>> queue will still accept more connections. Obviously the risk are
>>>>> the
>>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>>>>> queue to
>>>>>>>>> complete.
>>>>>>>>>
>>>>>>>>> As for XenServer, it's happening in what appears to be a similar
>>>>> way
>>>>>>>>> (although the source host is the target for the migration API
>>>>> call).
>>>>>>>>>
>>>>>>>>> Check
>>>>>>>>>
>>>>>>>>
>>>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>>>>>>>>
>>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>>>>>>>>> migrations. Any experts know the answer to if it can handle
>>>>> concurrency
>>>>>>>>> in a stable way?
>>>>>>>>>
>>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>>>>> operations.
>>>>>>>>>
>>>>>>>>> So do the HV experts on the list have any opinions about XenServer
>>>>> and
>>>>>>>>> KVM migration concurrency?
>>>>>>>>>
>>>>>>>>> -chip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
I see. Thanks for the information, Alex.
Alex Ough
On Thu, Nov 21, 2013 at 9:22 AM, Alex Huang <Al...@citrix.com> wrote:
> It’s because we switched over to a new way to declare configuration
> variables. Here’s some information about it.
>
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
>
>
>
> --Alex
>
>
>
> *From:* Alex Ough [mailto:alex.ough@sungard.com]
> *Sent:* Wednesday, November 20, 2013 9:56 AM
> *To:* Alex Huang
> *Cc:* dev@cloudstack.apache.org
> *Subject:* Re: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Hi Alex,
>
>
>
> It looks like you moved the 'ExecuteInSequence' to the vm level from the
> management server, which seems to be ok, but at this time I cannot test it
>
> because when I try to start up the management server, it fails because of
> database schema error, which is 'Unknown column 'disk_offering.cache_mode'
> in 'field list' even if I re-built the database.
>
>
>
> Is the schema change part of your changes or something other developer
> changed?
>
>
>
> If that is from any other developer, can you fix this?
>
>
>
> Thanks
>
> Alex Ough
>
>
>
>
>
>
>
> On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com> wrote:
>
> Alex,
>
>
>
> Can you do a pull from master and see if my fix fits your needs.
> Unfortunately, I’m on the road and couldn’t do an actual test of it.
>
>
>
> --Alex
>
>
>
> *From:* Alex Huang
> *Sent:* Tuesday, November 19, 2013 4:45 AM
> *To:* 'Alex Ough'; dev@cloudstack.apache.org
> *Subject:* RE: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Alex,
>
>
>
> Sorry for the late reply. Been travelling the last couple of weeks. I’ll
> look into this today.
>
>
>
> --Alex
>
>
>
> *From:* Alex Ough [mailto:alex.ough@sungard.com <al...@sungard.com>]
> *Sent:* Monday, November 18, 2013 6:17 AM
> *To:* dev@cloudstack.apache.org
> *Cc:* Alex Huang
> *Subject:* Re: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Thank Parasanna & Sebastien,
>
> I also got his email and sent an email.
>
> Waiting for his reply...
>
>
>
> Thanks
>
> Alex Ough
>
>
>
> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
>
> cc Alex Huang to get his attention:
>
>
>
> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
>
> > Alex, Could you just do a git blame on the file and copy the emails of
> > people who changed that bit of code? They may be able to help if Cc-ed
> > directly.
> >
> > Thanks,
> >
> > On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> >> I hate to sending the same emails over and over again, but I really
> need to
> >> finalize this feature to be included in the next code freeze because
> this
> >> feature is very critical in our inside project.
> >>
> >> Anyone who can help, please?
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
> wrote:
> >>
> >>> Not sure if Alex Huang checked this, but can anyone help to resolve
> this?
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
> wrote:
> >>>
> >>>> It sounds a little scary...
> >>>>
> >>>> I looked at the history and found these.
> >>>>
> >>>> 8/9/ : file moved to engine by Alex Huang
> >>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> >>>> 'getExecuteInSequence()' by Alex Huang
> >>>>
> >>>>
> >>>> Hi Alex Huang,
> >>>> I'm not sure if you're aware of this, but can you check this for me?
> >>>>
> >>>> Thanks
> >>>> Alex Ough
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
> shadowsor@gmail.com>wrote:
> >>>>
> >>>>> I'm not sure. I know in the past when I've seen files change
> locations
> >>>>> it has also clobbered updates to that file. Someone branched, did the
> >>>>> reorganization work, and merged, while in-between the original file
> >>>>> changed.
> >>>>>
> >>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>> All,
> >>>>>>
> >>>>>> While merging my changes to 4.3 branch, I found that the option,
> >>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
> >>>>> Start/Stop/Copy
> >>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
> >>>>>>
> >>>>>>
> >>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> >>>>>>
> >>>>>> *protected boolean getExecuteInSequence() {*
> >>>>>> * return false;*
> >>>>>> *}*
> >>>>>>
> >>>>>> As you see in the above, the function, 'getExecuteInSequence', just
> >>>>> returns
> >>>>>> false instead of getting the value from the global variable.
> >>>>>>
> >>>>>> And one more change is that the file has been moved to
> >>>>>> 'engine/orchestration/src/com/cloud/vm' from
> 'server/src/com/cloud/vm'.
> >>>>>>
> >>>>>> Am I missing something related with this or do we stop supporting
> this
> >>>>>> option in 4.3?
> >>>>>> I'm a little confused, so please help me resolve this.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Alex Ough
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Thanks a lot for your confirmation, Marcus.
> >>>>>>> I'll create a review request unless anyone has an objection.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Alex Ough
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
> shadowsor@gmail.com
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> I have done parallel KVM migrations without issue, it's "supposed
> to
> >>>>>>>> work". Really I think it's in the same boat as parallel
> start/stop.
> >>>>> It
> >>>>>>>> should work, but the config option is there just in case. I think
> we
> >>>>>>>> should add it.
> >>>>>>>>
> >>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>>>>>>> <ch...@sungard.com> wrote:
> >>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> In the case of VMware, the migrate command is executed via the
> >>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
> >>>>>>>>>
> >>>>>
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>>>>>>>>
> >>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
> >>>>>>>>> requests for migrations. Specifically, it will throttle the
> >>>>> migrations
> >>>>>>>>> happening, based on it's internal concurrency constraints, but
> the
> >>>>> task
> >>>>>>>>> queue will still accept more connections. Obviously the risk are
> >>>>> the
> >>>>>>>>> VMware layer tasks timing out if it takes too long for the task
> >>>>> queue to
> >>>>>>>>> complete.
> >>>>>>>>>
> >>>>>>>>> As for XenServer, it's happening in what appears to be a similar
> >>>>> way
> >>>>>>>>> (although the source host is the target for the migration API
> >>>>> call).
> >>>>>>>>>
> >>>>>>>>> Check
> >>>>>>>>>
> >>>>>>>>
> >>>>>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>>>>>>>>
> >>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
> >>>>>>>>> migrations. Any experts know the answer to if it can handle
> >>>>> concurrency
> >>>>>>>>> in a stable way?
> >>>>>>>>>
> >>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
> >>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
> >>>>> operations.
> >>>>>>>>>
> >>>>>>>>> So do the HV experts on the list have any opinions about
> XenServer
> >>>>> and
> >>>>>>>>> KVM migration concurrency?
> >>>>>>>>>
> >>>>>>>>> -chip
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > --
> > Prasanna.,
> >
> > ------------------------
> > Powered by BigRock.com
> >
>
>
>
>
>
RE: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Alex Huang <Al...@citrix.com>.
It's because we switched over to a new way to declare configuration variables. Here's some information about it.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuration
--Alex
From: Alex Ough [mailto:alex.ough@sungard.com]
Sent: Wednesday, November 20, 2013 9:56 AM
To: Alex Huang
Cc: dev@cloudstack.apache.org
Subject: Re: A question on vm migrations when hosts are set into a maintenance mode.
Hi Alex,
It looks like you moved the 'ExecuteInSequence' to the vm level from the management server, which seems to be ok, but at this time I cannot test it
because when I try to start up the management server, it fails because of database schema error, which is 'Unknown column 'disk_offering.cache_mode' in 'field list' even if I re-built the database.
Is the schema change part of your changes or something other developer changed?
If that is from any other developer, can you fix this?
Thanks
Alex Ough
On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com>> wrote:
Alex,
Can you do a pull from master and see if my fix fits your needs. Unfortunately, I'm on the road and couldn't do an actual test of it.
--Alex
From: Alex Huang
Sent: Tuesday, November 19, 2013 4:45 AM
To: 'Alex Ough'; dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Subject: RE: A question on vm migrations when hosts are set into a maintenance mode.
Alex,
Sorry for the late reply. Been travelling the last couple of weeks. I'll look into this today.
--Alex
From: Alex Ough [mailto:alex.ough@sungard.com]
Sent: Monday, November 18, 2013 6:17 AM
To: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Cc: Alex Huang
Subject: Re: A question on vm migrations when hosts are set into a maintenance mode.
Thank Parasanna & Sebastien,
I also got his email and sent an email.
Waiting for his reply...
Thanks
Alex Ough
On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>> wrote:
cc Alex Huang to get his attention:
On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org>> wrote:
> Alex, Could you just do a git blame on the file and copy the emails of
> people who changed that bit of code? They may be able to help if Cc-ed
> directly.
>
> Thanks,
>
> On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>> I hate to sending the same emails over and over again, but I really need to
>> finalize this feature to be included in the next code freeze because this
>> feature is very critical in our inside project.
>>
>> Anyone who can help, please?
>> Thanks
>> Alex Ough
>>
>>
>> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>> wrote:
>>
>>> Not sure if Alex Huang checked this, but can anyone help to resolve this?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>> wrote:
>>>
>>>> It sounds a little scary...
>>>>
>>>> I looked at the history and found these.
>>>>
>>>> 8/9/ : file moved to engine by Alex Huang
>>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>>>> 'getExecuteInSequence()' by Alex Huang
>>>>
>>>>
>>>> Hi Alex Huang,
>>>> I'm not sure if you're aware of this, but can you check this for me?
>>>>
>>>> Thanks
>>>> Alex Ough
>>>>
>>>>
>>>>
>>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>>wrote:
>>>>
>>>>> I'm not sure. I know in the past when I've seen files change locations
>>>>> it has also clobbered updates to that file. Someone branched, did the
>>>>> reorganization work, and merged, while in-between the original file
>>>>> changed.
>>>>>
>>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>> All,
>>>>>>
>>>>>> While merging my changes to 4.3 branch, I found that the option,
>>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>>>>> Start/Stop/Copy
>>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>>>>>>
>>>>>>
>>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>>>>>
>>>>>> *protected boolean getExecuteInSequence() {*
>>>>>> * return false;*
>>>>>> *}*
>>>>>>
>>>>>> As you see in the above, the function, 'getExecuteInSequence', just
>>>>> returns
>>>>>> false instead of getting the value from the global variable.
>>>>>>
>>>>>> And one more change is that the file has been moved to
>>>>>> 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>>>>>>
>>>>>> Am I missing something related with this or do we stop supporting this
>>>>>> option in 4.3?
>>>>>> I'm a little confused, so please help me resolve this.
>>>>>>
>>>>>> Thanks
>>>>>> Alex Ough
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>>
>>>>>>> Thanks a lot for your confirmation, Marcus.
>>>>>>> I'll create a review request unless anyone has an objection.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Alex Ough
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I have done parallel KVM migrations without issue, it's "supposed to
>>>>>>>> work". Really I think it's in the same boat as parallel start/stop.
>>>>> It
>>>>>>>> should work, but the config option is there just in case. I think we
>>>>>>>> should add it.
>>>>>>>>
>>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>>>>>>> <ch...@sungard.com>> wrote:
>>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> In the case of VMware, the migrate command is executed via the
>>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>>>>>>>>>
>>>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>>>>>>>>
>>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
>>>>>>>>> requests for migrations. Specifically, it will throttle the
>>>>> migrations
>>>>>>>>> happening, based on it's internal concurrency constraints, but the
>>>>> task
>>>>>>>>> queue will still accept more connections. Obviously the risk are
>>>>> the
>>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>>>>> queue to
>>>>>>>>> complete.
>>>>>>>>>
>>>>>>>>> As for XenServer, it's happening in what appears to be a similar
>>>>> way
>>>>>>>>> (although the source host is the target for the migration API
>>>>> call).
>>>>>>>>>
>>>>>>>>> Check
>>>>>>>>>
>>>>>>>>
>>>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>>>>>>>>
>>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>>>>>>>>> migrations. Any experts know the answer to if it can handle
>>>>> concurrency
>>>>>>>>> in a stable way?
>>>>>>>>>
>>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>>>>> operations.
>>>>>>>>>
>>>>>>>>> So do the HV experts on the list have any opinions about XenServer
>>>>> and
>>>>>>>>> KVM migration concurrency?
>>>>>>>>>
>>>>>>>>> -chip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
Hi Alex,
It looks like you moved the 'ExecuteInSequence' to the vm level from the
management server, which seems to be ok, but at this time I cannot test it
because when I try to start up the management server, it fails because of
database schema error, which is 'Unknown column 'disk_offering.cache_mode'
in 'field list' even if I re-built the database.
Is the schema change part of your changes or something other developer
changed?
If that is from any other developer, can you fix this?
Thanks
Alex Ough
On Tue, Nov 19, 2013 at 7:25 PM, Alex Huang <Al...@citrix.com> wrote:
> Alex,
>
>
>
> Can you do a pull from master and see if my fix fits your needs.
> Unfortunately, I’m on the road and couldn’t do an actual test of it.
>
>
>
> --Alex
>
>
>
> *From:* Alex Huang
> *Sent:* Tuesday, November 19, 2013 4:45 AM
> *To:* 'Alex Ough'; dev@cloudstack.apache.org
> *Subject:* RE: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Alex,
>
>
>
> Sorry for the late reply. Been travelling the last couple of weeks. I’ll
> look into this today.
>
>
>
> --Alex
>
>
>
> *From:* Alex Ough [mailto:alex.ough@sungard.com <al...@sungard.com>]
> *Sent:* Monday, November 18, 2013 6:17 AM
> *To:* dev@cloudstack.apache.org
> *Cc:* Alex Huang
> *Subject:* Re: A question on vm migrations when hosts are set into a
> maintenance mode.
>
>
>
> Thank Parasanna & Sebastien,
>
> I also got his email and sent an email.
>
> Waiting for his reply...
>
>
>
> Thanks
>
> Alex Ough
>
>
>
> On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
>
> cc Alex Huang to get his attention:
>
>
>
> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
>
> > Alex, Could you just do a git blame on the file and copy the emails of
> > people who changed that bit of code? They may be able to help if Cc-ed
> > directly.
> >
> > Thanks,
> >
> > On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> >> I hate to sending the same emails over and over again, but I really
> need to
> >> finalize this feature to be included in the next code freeze because
> this
> >> feature is very critical in our inside project.
> >>
> >> Anyone who can help, please?
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
> wrote:
> >>
> >>> Not sure if Alex Huang checked this, but can anyone help to resolve
> this?
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
> wrote:
> >>>
> >>>> It sounds a little scary...
> >>>>
> >>>> I looked at the history and found these.
> >>>>
> >>>> 8/9/ : file moved to engine by Alex Huang
> >>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> >>>> 'getExecuteInSequence()' by Alex Huang
> >>>>
> >>>>
> >>>> Hi Alex Huang,
> >>>> I'm not sure if you're aware of this, but can you check this for me?
> >>>>
> >>>> Thanks
> >>>> Alex Ough
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
> shadowsor@gmail.com>wrote:
> >>>>
> >>>>> I'm not sure. I know in the past when I've seen files change
> locations
> >>>>> it has also clobbered updates to that file. Someone branched, did the
> >>>>> reorganization work, and merged, while in-between the original file
> >>>>> changed.
> >>>>>
> >>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>> All,
> >>>>>>
> >>>>>> While merging my changes to 4.3 branch, I found that the option,
> >>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
> >>>>> Start/Stop/Copy
> >>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
> >>>>>>
> >>>>>>
> >>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> >>>>>>
> >>>>>> *protected boolean getExecuteInSequence() {*
> >>>>>> * return false;*
> >>>>>> *}*
> >>>>>>
> >>>>>> As you see in the above, the function, 'getExecuteInSequence', just
> >>>>> returns
> >>>>>> false instead of getting the value from the global variable.
> >>>>>>
> >>>>>> And one more change is that the file has been moved to
> >>>>>> 'engine/orchestration/src/com/cloud/vm' from
> 'server/src/com/cloud/vm'.
> >>>>>>
> >>>>>> Am I missing something related with this or do we stop supporting
> this
> >>>>>> option in 4.3?
> >>>>>> I'm a little confused, so please help me resolve this.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Alex Ough
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Thanks a lot for your confirmation, Marcus.
> >>>>>>> I'll create a review request unless anyone has an objection.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Alex Ough
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
> shadowsor@gmail.com
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> I have done parallel KVM migrations without issue, it's "supposed
> to
> >>>>>>>> work". Really I think it's in the same boat as parallel
> start/stop.
> >>>>> It
> >>>>>>>> should work, but the config option is there just in case. I think
> we
> >>>>>>>> should add it.
> >>>>>>>>
> >>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>>>>>>> <ch...@sungard.com> wrote:
> >>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> In the case of VMware, the migrate command is executed via the
> >>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
> >>>>>>>>>
> >>>>>
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>>>>>>>>
> >>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
> >>>>>>>>> requests for migrations. Specifically, it will throttle the
> >>>>> migrations
> >>>>>>>>> happening, based on it's internal concurrency constraints, but
> the
> >>>>> task
> >>>>>>>>> queue will still accept more connections. Obviously the risk are
> >>>>> the
> >>>>>>>>> VMware layer tasks timing out if it takes too long for the task
> >>>>> queue to
> >>>>>>>>> complete.
> >>>>>>>>>
> >>>>>>>>> As for XenServer, it's happening in what appears to be a similar
> >>>>> way
> >>>>>>>>> (although the source host is the target for the migration API
> >>>>> call).
> >>>>>>>>>
> >>>>>>>>> Check
> >>>>>>>>>
> >>>>>>>>
> >>>>>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>>>>>>>>
> >>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
> >>>>>>>>> migrations. Any experts know the answer to if it can handle
> >>>>> concurrency
> >>>>>>>>> in a stable way?
> >>>>>>>>>
> >>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
> >>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
> >>>>> operations.
> >>>>>>>>>
> >>>>>>>>> So do the HV experts on the list have any opinions about
> XenServer
> >>>>> and
> >>>>>>>>> KVM migration concurrency?
> >>>>>>>>>
> >>>>>>>>> -chip
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > --
> > Prasanna.,
> >
> > ------------------------
> > Powered by BigRock.com
> >
>
>
>
RE: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Alex Huang <Al...@citrix.com>.
Alex,
Can you do a pull from master and see if my fix fits your needs. Unfortunately, I'm on the road and couldn't do an actual test of it.
--Alex
From: Alex Huang
Sent: Tuesday, November 19, 2013 4:45 AM
To: 'Alex Ough'; dev@cloudstack.apache.org
Subject: RE: A question on vm migrations when hosts are set into a maintenance mode.
Alex,
Sorry for the late reply. Been travelling the last couple of weeks. I'll look into this today.
--Alex
From: Alex Ough [mailto:alex.ough@sungard.com]
Sent: Monday, November 18, 2013 6:17 AM
To: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Cc: Alex Huang
Subject: Re: A question on vm migrations when hosts are set into a maintenance mode.
Thank Parasanna & Sebastien,
I also got his email and sent an email.
Waiting for his reply...
Thanks
Alex Ough
On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>> wrote:
cc Alex Huang to get his attention:
On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org>> wrote:
> Alex, Could you just do a git blame on the file and copy the emails of
> people who changed that bit of code? They may be able to help if Cc-ed
> directly.
>
> Thanks,
>
> On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>> I hate to sending the same emails over and over again, but I really need to
>> finalize this feature to be included in the next code freeze because this
>> feature is very critical in our inside project.
>>
>> Anyone who can help, please?
>> Thanks
>> Alex Ough
>>
>>
>> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>> wrote:
>>
>>> Not sure if Alex Huang checked this, but can anyone help to resolve this?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>> wrote:
>>>
>>>> It sounds a little scary...
>>>>
>>>> I looked at the history and found these.
>>>>
>>>> 8/9/ : file moved to engine by Alex Huang
>>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>>>> 'getExecuteInSequence()' by Alex Huang
>>>>
>>>>
>>>> Hi Alex Huang,
>>>> I'm not sure if you're aware of this, but can you check this for me?
>>>>
>>>> Thanks
>>>> Alex Ough
>>>>
>>>>
>>>>
>>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>>wrote:
>>>>
>>>>> I'm not sure. I know in the past when I've seen files change locations
>>>>> it has also clobbered updates to that file. Someone branched, did the
>>>>> reorganization work, and merged, while in-between the original file
>>>>> changed.
>>>>>
>>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>> All,
>>>>>>
>>>>>> While merging my changes to 4.3 branch, I found that the option,
>>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>>>>> Start/Stop/Copy
>>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>>>>>>
>>>>>>
>>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>>>>>
>>>>>> *protected boolean getExecuteInSequence() {*
>>>>>> * return false;*
>>>>>> *}*
>>>>>>
>>>>>> As you see in the above, the function, 'getExecuteInSequence', just
>>>>> returns
>>>>>> false instead of getting the value from the global variable.
>>>>>>
>>>>>> And one more change is that the file has been moved to
>>>>>> 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>>>>>>
>>>>>> Am I missing something related with this or do we stop supporting this
>>>>>> option in 4.3?
>>>>>> I'm a little confused, so please help me resolve this.
>>>>>>
>>>>>> Thanks
>>>>>> Alex Ough
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>>
>>>>>>> Thanks a lot for your confirmation, Marcus.
>>>>>>> I'll create a review request unless anyone has an objection.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Alex Ough
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I have done parallel KVM migrations without issue, it's "supposed to
>>>>>>>> work". Really I think it's in the same boat as parallel start/stop.
>>>>> It
>>>>>>>> should work, but the config option is there just in case. I think we
>>>>>>>> should add it.
>>>>>>>>
>>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>>>>>>> <ch...@sungard.com>> wrote:
>>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> In the case of VMware, the migrate command is executed via the
>>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>>>>>>>>>
>>>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>>>>>>>>
>>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
>>>>>>>>> requests for migrations. Specifically, it will throttle the
>>>>> migrations
>>>>>>>>> happening, based on it's internal concurrency constraints, but the
>>>>> task
>>>>>>>>> queue will still accept more connections. Obviously the risk are
>>>>> the
>>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>>>>> queue to
>>>>>>>>> complete.
>>>>>>>>>
>>>>>>>>> As for XenServer, it's happening in what appears to be a similar
>>>>> way
>>>>>>>>> (although the source host is the target for the migration API
>>>>> call).
>>>>>>>>>
>>>>>>>>> Check
>>>>>>>>>
>>>>>>>>
>>>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>>>>>>>>
>>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>>>>>>>>> migrations. Any experts know the answer to if it can handle
>>>>> concurrency
>>>>>>>>> in a stable way?
>>>>>>>>>
>>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>>>>> operations.
>>>>>>>>>
>>>>>>>>> So do the HV experts on the list have any opinions about XenServer
>>>>> and
>>>>>>>>> KVM migration concurrency?
>>>>>>>>>
>>>>>>>>> -chip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
RE: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Alex Huang <Al...@citrix.com>.
Alex,
Sorry for the late reply. Been travelling the last couple of weeks. I'll look into this today.
--Alex
From: Alex Ough [mailto:alex.ough@sungard.com]
Sent: Monday, November 18, 2013 6:17 AM
To: dev@cloudstack.apache.org
Cc: Alex Huang
Subject: Re: A question on vm migrations when hosts are set into a maintenance mode.
Thank Parasanna & Sebastien,
I also got his email and sent an email.
Waiting for his reply...
Thanks
Alex Ough
On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>> wrote:
cc Alex Huang to get his attention:
On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org>> wrote:
> Alex, Could you just do a git blame on the file and copy the emails of
> people who changed that bit of code? They may be able to help if Cc-ed
> directly.
>
> Thanks,
>
> On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>> I hate to sending the same emails over and over again, but I really need to
>> finalize this feature to be included in the next code freeze because this
>> feature is very critical in our inside project.
>>
>> Anyone who can help, please?
>> Thanks
>> Alex Ough
>>
>>
>> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>> wrote:
>>
>>> Not sure if Alex Huang checked this, but can anyone help to resolve this?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>> wrote:
>>>
>>>> It sounds a little scary...
>>>>
>>>> I looked at the history and found these.
>>>>
>>>> 8/9/ : file moved to engine by Alex Huang
>>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>>>> 'getExecuteInSequence()' by Alex Huang
>>>>
>>>>
>>>> Hi Alex Huang,
>>>> I'm not sure if you're aware of this, but can you check this for me?
>>>>
>>>> Thanks
>>>> Alex Ough
>>>>
>>>>
>>>>
>>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>>wrote:
>>>>
>>>>> I'm not sure. I know in the past when I've seen files change locations
>>>>> it has also clobbered updates to that file. Someone branched, did the
>>>>> reorganization work, and merged, while in-between the original file
>>>>> changed.
>>>>>
>>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>> All,
>>>>>>
>>>>>> While merging my changes to 4.3 branch, I found that the option,
>>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>>>>> Start/Stop/Copy
>>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>>>>>>
>>>>>>
>>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>>>>>
>>>>>> *protected boolean getExecuteInSequence() {*
>>>>>> * return false;*
>>>>>> *}*
>>>>>>
>>>>>> As you see in the above, the function, 'getExecuteInSequence', just
>>>>> returns
>>>>>> false instead of getting the value from the global variable.
>>>>>>
>>>>>> And one more change is that the file has been moved to
>>>>>> 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>>>>>>
>>>>>> Am I missing something related with this or do we stop supporting this
>>>>>> option in 4.3?
>>>>>> I'm a little confused, so please help me resolve this.
>>>>>>
>>>>>> Thanks
>>>>>> Alex Ough
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>>
>>>>> wrote:
>>>>>>
>>>>>>> Thanks a lot for your confirmation, Marcus.
>>>>>>> I'll create a review request unless anyone has an objection.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Alex Ough
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <sh...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I have done parallel KVM migrations without issue, it's "supposed to
>>>>>>>> work". Really I think it's in the same boat as parallel start/stop.
>>>>> It
>>>>>>>> should work, but the config option is there just in case. I think we
>>>>>>>> should add it.
>>>>>>>>
>>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>>>>>>> <ch...@sungard.com>> wrote:
>>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> In the case of VMware, the migrate command is executed via the
>>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>>>>>>>>>
>>>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>>>>>>>>
>>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
>>>>>>>>> requests for migrations. Specifically, it will throttle the
>>>>> migrations
>>>>>>>>> happening, based on it's internal concurrency constraints, but the
>>>>> task
>>>>>>>>> queue will still accept more connections. Obviously the risk are
>>>>> the
>>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>>>>> queue to
>>>>>>>>> complete.
>>>>>>>>>
>>>>>>>>> As for XenServer, it's happening in what appears to be a similar
>>>>> way
>>>>>>>>> (although the source host is the target for the migration API
>>>>> call).
>>>>>>>>>
>>>>>>>>> Check
>>>>>>>>>
>>>>>>>>
>>>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>>>>>>>>
>>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>>>>>>>>> migrations. Any experts know the answer to if it can handle
>>>>> concurrency
>>>>>>>>> in a stable way?
>>>>>>>>>
>>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>>>>> operations.
>>>>>>>>>
>>>>>>>>> So do the HV experts on the list have any opinions about XenServer
>>>>> and
>>>>>>>>> KVM migration concurrency?
>>>>>>>>>
>>>>>>>>> -chip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
Thank Parasanna & Sebastien,
I also got his email and sent an email.
Waiting for his reply...
Thanks
Alex Ough
On Sat, Nov 16, 2013 at 3:05 PM, Sebastien Goasguen <ru...@gmail.com>wrote:
> cc Alex Huang to get his attention:
>
>
> On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
>
> > Alex, Could you just do a git blame on the file and copy the emails of
> > people who changed that bit of code? They may be able to help if Cc-ed
> > directly.
> >
> > Thanks,
> >
> > On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> >> I hate to sending the same emails over and over again, but I really
> need to
> >> finalize this feature to be included in the next code freeze because
> this
> >> feature is very critical in our inside project.
> >>
> >> Anyone who can help, please?
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com>
> wrote:
> >>
> >>> Not sure if Alex Huang checked this, but can anyone help to resolve
> this?
> >>>
> >>> Thanks
> >>> Alex Ough
> >>>
> >>>
> >>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com>
> wrote:
> >>>
> >>>> It sounds a little scary...
> >>>>
> >>>> I looked at the history and found these.
> >>>>
> >>>> 8/9/ : file moved to engine by Alex Huang
> >>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> >>>> 'getExecuteInSequence()' by Alex Huang
> >>>>
> >>>>
> >>>> Hi Alex Huang,
> >>>> I'm not sure if you're aware of this, but can you check this for me?
> >>>>
> >>>> Thanks
> >>>> Alex Ough
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <
> shadowsor@gmail.com>wrote:
> >>>>
> >>>>> I'm not sure. I know in the past when I've seen files change
> locations
> >>>>> it has also clobbered updates to that file. Someone branched, did the
> >>>>> reorganization work, and merged, while in-between the original file
> >>>>> changed.
> >>>>>
> >>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>> All,
> >>>>>>
> >>>>>> While merging my changes to 4.3 branch, I found that the option,
> >>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
> >>>>> Start/Stop/Copy
> >>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
> >>>>>>
> >>>>>>
> >>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> >>>>>>
> >>>>>> *protected boolean getExecuteInSequence() {*
> >>>>>> * return false;*
> >>>>>> *}*
> >>>>>>
> >>>>>> As you see in the above, the function, 'getExecuteInSequence', just
> >>>>> returns
> >>>>>> false instead of getting the value from the global variable.
> >>>>>>
> >>>>>> And one more change is that the file has been moved to
> >>>>>> 'engine/orchestration/src/com/cloud/vm' from
> 'server/src/com/cloud/vm'.
> >>>>>>
> >>>>>> Am I missing something related with this or do we stop supporting
> this
> >>>>>> option in 4.3?
> >>>>>> I'm a little confused, so please help me resolve this.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Alex Ough
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Thanks a lot for your confirmation, Marcus.
> >>>>>>> I'll create a review request unless anyone has an objection.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Alex Ough
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <
> shadowsor@gmail.com
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> I have done parallel KVM migrations without issue, it's "supposed
> to
> >>>>>>>> work". Really I think it's in the same boat as parallel
> start/stop.
> >>>>> It
> >>>>>>>> should work, but the config option is there just in case. I think
> we
> >>>>>>>> should add it.
> >>>>>>>>
> >>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>>>>>>> <ch...@sungard.com> wrote:
> >>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>>>>>>>>> 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
> >>>>>>>>>
> >>>>>>>>> In the case of VMware, the migrate command is executed via the
> >>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
> >>>>>>>>>
> >>>>>
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>>>>>>>>
> >>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
> >>>>>>>>> requests for migrations. Specifically, it will throttle the
> >>>>> migrations
> >>>>>>>>> happening, based on it's internal concurrency constraints, but
> the
> >>>>> task
> >>>>>>>>> queue will still accept more connections. Obviously the risk are
> >>>>> the
> >>>>>>>>> VMware layer tasks timing out if it takes too long for the task
> >>>>> queue to
> >>>>>>>>> complete.
> >>>>>>>>>
> >>>>>>>>> As for XenServer, it's happening in what appears to be a similar
> >>>>> way
> >>>>>>>>> (although the source host is the target for the migration API
> >>>>> call).
> >>>>>>>>>
> >>>>>>>>> Check
> >>>>>>>>>
> >>>>>>>>
> >>>>>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>>>>>>>>
> >>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
> >>>>>>>>> migrations. Any experts know the answer to if it can handle
> >>>>> concurrency
> >>>>>>>>> in a stable way?
> >>>>>>>>>
> >>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
> >>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
> >>>>> operations.
> >>>>>>>>>
> >>>>>>>>> So do the HV experts on the list have any opinions about
> XenServer
> >>>>> and
> >>>>>>>>> KVM migration concurrency?
> >>>>>>>>>
> >>>>>>>>> -chip
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> > --
> > Prasanna.,
> >
> > ------------------------
> > Powered by BigRock.com
> >
>
>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Sebastien Goasguen <ru...@gmail.com>.
cc Alex Huang to get his attention:
On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <ts...@apache.org> wrote:
> Alex, Could you just do a git blame on the file and copy the emails of
> people who changed that bit of code? They may be able to help if Cc-ed
> directly.
>
> Thanks,
>
> On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
>> I hate to sending the same emails over and over again, but I really need to
>> finalize this feature to be included in the next code freeze because this
>> feature is very critical in our inside project.
>>
>> Anyone who can help, please?
>> Thanks
>> Alex Ough
>>
>>
>> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com> wrote:
>>
>>> Not sure if Alex Huang checked this, but can anyone help to resolve this?
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com> wrote:
>>>
>>>> It sounds a little scary...
>>>>
>>>> I looked at the history and found these.
>>>>
>>>> 8/9/ : file moved to engine by Alex Huang
>>>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>>>> 'getExecuteInSequence()' by Alex Huang
>>>>
>>>>
>>>> Hi Alex Huang,
>>>> I'm not sure if you're aware of this, but can you check this for me?
>>>>
>>>> Thanks
>>>> Alex Ough
>>>>
>>>>
>>>>
>>>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>wrote:
>>>>
>>>>> I'm not sure. I know in the past when I've seen files change locations
>>>>> it has also clobbered updates to that file. Someone branched, did the
>>>>> reorganization work, and merged, while in-between the original file
>>>>> changed.
>>>>>
>>>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
>>>>> wrote:
>>>>>> All,
>>>>>>
>>>>>> While merging my changes to 4.3 branch, I found that the option,
>>>>>> 'execute.in.sequence.hypervisor.commands' is NOT used in
>>>>> Start/Stop/Copy
>>>>>> commands in 'VirtualMachineManagerImpl.java' any more as below.
>>>>>>
>>>>>>
>>>>>> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>>>>>
>>>>>> *protected boolean getExecuteInSequence() {*
>>>>>> * return false;*
>>>>>> *}*
>>>>>>
>>>>>> As you see in the above, the function, 'getExecuteInSequence', just
>>>>> returns
>>>>>> false instead of getting the value from the global variable.
>>>>>>
>>>>>> And one more change is that the file has been moved to
>>>>>> 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>>>>>>
>>>>>> Am I missing something related with this or do we stop supporting this
>>>>>> option in 4.3?
>>>>>> I'm a little confused, so please help me resolve this.
>>>>>>
>>>>>> Thanks
>>>>>> Alex Ough
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
>>>>> wrote:
>>>>>>
>>>>>>> Thanks a lot for your confirmation, Marcus.
>>>>>>> I'll create a review request unless anyone has an objection.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Alex Ough
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <shadowsor@gmail.com
>>>>>> wrote:
>>>>>>>
>>>>>>>> I have done parallel KVM migrations without issue, it's "supposed to
>>>>>>>> work". Really I think it's in the same boat as parallel start/stop.
>>>>> It
>>>>>>>> should work, but the config option is there just in case. I think we
>>>>>>>> should add it.
>>>>>>>>
>>>>>>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>>>>>>> <ch...@sungard.com> wrote:
>>>>>>>>> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>> In the case of VMware, the migrate command is executed via the
>>>>>>>>> MigrateVMTask that's part of the VMware SDK (see
>>>>>>>>>
>>>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>>>>>>>>
>>>>>>>>> For VMware, I know that vCenter will queue and process concurrent
>>>>>>>>> requests for migrations. Specifically, it will throttle the
>>>>> migrations
>>>>>>>>> happening, based on it's internal concurrency constraints, but the
>>>>> task
>>>>>>>>> queue will still accept more connections. Obviously the risk are
>>>>> the
>>>>>>>>> VMware layer tasks timing out if it takes too long for the task
>>>>> queue to
>>>>>>>>> complete.
>>>>>>>>>
>>>>>>>>> As for XenServer, it's happening in what appears to be a similar
>>>>> way
>>>>>>>>> (although the source host is the target for the migration API
>>>>> call).
>>>>>>>>>
>>>>>>>>> Check
>>>>>>>>>
>>>>>>>>
>>>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>>>>>>>>
>>>>>>>>> I'm not familiar enough with XenServer's concurrency model for
>>>>>>>>> migrations. Any experts know the answer to if it can handle
>>>>> concurrency
>>>>>>>>> in a stable way?
>>>>>>>>>
>>>>>>>>> With KVM, it's obviously executing via the agent. Similarly to
>>>>>>>>> XenServer, I'm not familiar enough to know about concurrent
>>>>> operations.
>>>>>>>>>
>>>>>>>>> So do the HV experts on the list have any opinions about XenServer
>>>>> and
>>>>>>>>> KVM migration concurrency?
>>>>>>>>>
>>>>>>>>> -chip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
Re: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Prasanna Santhanam <ts...@apache.org>.
Alex, Could you just do a git blame on the file and copy the emails of
people who changed that bit of code? They may be able to help if Cc-ed
directly.
Thanks,
On Fri, Nov 15, 2013 at 01:49:07PM -0600, Alex Ough wrote:
> I hate to sending the same emails over and over again, but I really need to
> finalize this feature to be included in the next code freeze because this
> feature is very critical in our inside project.
>
> Anyone who can help, please?
> Thanks
> Alex Ough
>
>
> On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com> wrote:
>
> > Not sure if Alex Huang checked this, but can anyone help to resolve this?
> >
> > Thanks
> > Alex Ough
> >
> >
> > On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com> wrote:
> >
> >> It sounds a little scary...
> >>
> >> I looked at the history and found these.
> >>
> >> 8/9/ : file moved to engine by Alex Huang
> >> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> >> 'getExecuteInSequence()' by Alex Huang
> >>
> >>
> >> Hi Alex Huang,
> >> I'm not sure if you're aware of this, but can you check this for me?
> >>
> >> Thanks
> >> Alex Ough
> >>
> >>
> >>
> >> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>wrote:
> >>
> >>> I'm not sure. I know in the past when I've seen files change locations
> >>> it has also clobbered updates to that file. Someone branched, did the
> >>> reorganization work, and merged, while in-between the original file
> >>> changed.
> >>>
> >>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
> >>> wrote:
> >>> > All,
> >>> >
> >>> > While merging my changes to 4.3 branch, I found that the option,
> >>> > 'execute.in.sequence.hypervisor.commands' is NOT used in
> >>> Start/Stop/Copy
> >>> > commands in 'VirtualMachineManagerImpl.java' any more as below.
> >>> >
> >>> >
> >>> > *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> >>> >
> >>> > *protected boolean getExecuteInSequence() {*
> >>> > * return false;*
> >>> > *}*
> >>> >
> >>> > As you see in the above, the function, 'getExecuteInSequence', just
> >>> returns
> >>> > false instead of getting the value from the global variable.
> >>> >
> >>> > And one more change is that the file has been moved to
> >>> > 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
> >>> >
> >>> > Am I missing something related with this or do we stop supporting this
> >>> > option in 4.3?
> >>> > I'm a little confused, so please help me resolve this.
> >>> >
> >>> > Thanks
> >>> > Alex Ough
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
> >>> wrote:
> >>> >
> >>> >> Thanks a lot for your confirmation, Marcus.
> >>> >> I'll create a review request unless anyone has an objection.
> >>> >>
> >>> >> Thanks
> >>> >> Alex Ough
> >>> >>
> >>> >>
> >>> >> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <shadowsor@gmail.com
> >>> >wrote:
> >>> >>
> >>> >>> I have done parallel KVM migrations without issue, it's "supposed to
> >>> >>> work". Really I think it's in the same boat as parallel start/stop.
> >>> It
> >>> >>> should work, but the config option is there just in case. I think we
> >>> >>> should add it.
> >>> >>>
> >>> >>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>> >>> <ch...@sungard.com> wrote:
> >>> >>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>> >>> >> 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
> >>> >>> >
> >>> >>> > In the case of VMware, the migrate command is executed via the
> >>> >>> > MigrateVMTask that's part of the VMware SDK (see
> >>> >>> >
> >>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>> >>> >
> >>> >>> > For VMware, I know that vCenter will queue and process concurrent
> >>> >>> > requests for migrations. Specifically, it will throttle the
> >>> migrations
> >>> >>> > happening, based on it's internal concurrency constraints, but the
> >>> task
> >>> >>> > queue will still accept more connections. Obviously the risk are
> >>> the
> >>> >>> > VMware layer tasks timing out if it takes too long for the task
> >>> queue to
> >>> >>> > complete.
> >>> >>> >
> >>> >>> > As for XenServer, it's happening in what appears to be a similar
> >>> way
> >>> >>> > (although the source host is the target for the migration API
> >>> call).
> >>> >>> >
> >>> >>> > Check
> >>> >>> >
> >>> >>>
> >>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>> >>> >
> >>> >>> > I'm not familiar enough with XenServer's concurrency model for
> >>> >>> > migrations. Any experts know the answer to if it can handle
> >>> concurrency
> >>> >>> > in a stable way?
> >>> >>> >
> >>> >>> > With KVM, it's obviously executing via the agent. Similarly to
> >>> >>> > XenServer, I'm not familiar enough to know about concurrent
> >>> operations.
> >>> >>> >
> >>> >>> > So do the HV experts on the list have any opinions about XenServer
> >>> and
> >>> >>> > KVM migration concurrency?
> >>> >>> >
> >>> >>> > -chip
> >>> >>> >
> >>> >>> >
> >>> >>>
> >>> >>>
> >>> >>
> >>>
> >>>
> >>
> >
--
Prasanna.,
------------------------
Powered by BigRock.com
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
I hate to sending the same emails over and over again, but I really need to
finalize this feature to be included in the next code freeze because this
feature is very critical in our inside project.
Anyone who can help, please?
Thanks
Alex Ough
On Thu, Nov 14, 2013 at 1:27 PM, Alex Ough <al...@sungard.com> wrote:
> Not sure if Alex Huang checked this, but can anyone help to resolve this?
>
> Thanks
> Alex Ough
>
>
> On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com> wrote:
>
>> It sounds a little scary...
>>
>> I looked at the history and found these.
>>
>> 8/9/ : file moved to engine by Alex Huang
>> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
>> 'getExecuteInSequence()' by Alex Huang
>>
>>
>> Hi Alex Huang,
>> I'm not sure if you're aware of this, but can you check this for me?
>>
>> Thanks
>> Alex Ough
>>
>>
>>
>> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>wrote:
>>
>>> I'm not sure. I know in the past when I've seen files change locations
>>> it has also clobbered updates to that file. Someone branched, did the
>>> reorganization work, and merged, while in-between the original file
>>> changed.
>>>
>>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com>
>>> wrote:
>>> > All,
>>> >
>>> > While merging my changes to 4.3 branch, I found that the option,
>>> > 'execute.in.sequence.hypervisor.commands' is NOT used in
>>> Start/Stop/Copy
>>> > commands in 'VirtualMachineManagerImpl.java' any more as below.
>>> >
>>> >
>>> > *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>>> >
>>> > *protected boolean getExecuteInSequence() {*
>>> > * return false;*
>>> > *}*
>>> >
>>> > As you see in the above, the function, 'getExecuteInSequence', just
>>> returns
>>> > false instead of getting the value from the global variable.
>>> >
>>> > And one more change is that the file has been moved to
>>> > 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>>> >
>>> > Am I missing something related with this or do we stop supporting this
>>> > option in 4.3?
>>> > I'm a little confused, so please help me resolve this.
>>> >
>>> > Thanks
>>> > Alex Ough
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
>>> wrote:
>>> >
>>> >> Thanks a lot for your confirmation, Marcus.
>>> >> I'll create a review request unless anyone has an objection.
>>> >>
>>> >> Thanks
>>> >> Alex Ough
>>> >>
>>> >>
>>> >> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <shadowsor@gmail.com
>>> >wrote:
>>> >>
>>> >>> I have done parallel KVM migrations without issue, it's "supposed to
>>> >>> work". Really I think it's in the same boat as parallel start/stop.
>>> It
>>> >>> should work, but the config option is there just in case. I think we
>>> >>> should add it.
>>> >>>
>>> >>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>> >>> <ch...@sungard.com> wrote:
>>> >>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>> >>> >> 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
>>> >>> >
>>> >>> > In the case of VMware, the migrate command is executed via the
>>> >>> > MigrateVMTask that's part of the VMware SDK (see
>>> >>> >
>>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>> >>> >
>>> >>> > For VMware, I know that vCenter will queue and process concurrent
>>> >>> > requests for migrations. Specifically, it will throttle the
>>> migrations
>>> >>> > happening, based on it's internal concurrency constraints, but the
>>> task
>>> >>> > queue will still accept more connections. Obviously the risk are
>>> the
>>> >>> > VMware layer tasks timing out if it takes too long for the task
>>> queue to
>>> >>> > complete.
>>> >>> >
>>> >>> > As for XenServer, it's happening in what appears to be a similar
>>> way
>>> >>> > (although the source host is the target for the migration API
>>> call).
>>> >>> >
>>> >>> > Check
>>> >>> >
>>> >>>
>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>> >>> >
>>> >>> > I'm not familiar enough with XenServer's concurrency model for
>>> >>> > migrations. Any experts know the answer to if it can handle
>>> concurrency
>>> >>> > in a stable way?
>>> >>> >
>>> >>> > With KVM, it's obviously executing via the agent. Similarly to
>>> >>> > XenServer, I'm not familiar enough to know about concurrent
>>> operations.
>>> >>> >
>>> >>> > So do the HV experts on the list have any opinions about XenServer
>>> and
>>> >>> > KVM migration concurrency?
>>> >>> >
>>> >>> > -chip
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> >>
>>>
>>>
>>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
Not sure if Alex Huang checked this, but can anyone help to resolve this?
Thanks
Alex Ough
On Wed, Nov 13, 2013 at 11:39 AM, Alex Ough <al...@sungard.com> wrote:
> It sounds a little scary...
>
> I looked at the history and found these.
>
> 8/9/ : file moved to engine by Alex Huang
> 9/16 : '_mgmtServer.getExecuteInSequence()' changed to
> 'getExecuteInSequence()' by Alex Huang
>
>
> Hi Alex Huang,
> I'm not sure if you're aware of this, but can you check this for me?
>
> Thanks
> Alex Ough
>
>
>
> On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>wrote:
>
>> I'm not sure. I know in the past when I've seen files change locations
>> it has also clobbered updates to that file. Someone branched, did the
>> reorganization work, and merged, while in-between the original file
>> changed.
>>
>> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com> wrote:
>> > All,
>> >
>> > While merging my changes to 4.3 branch, I found that the option,
>> > 'execute.in.sequence.hypervisor.commands' is NOT used in Start/Stop/Copy
>> > commands in 'VirtualMachineManagerImpl.java' any more as below.
>> >
>> >
>> > *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>> >
>> > *protected boolean getExecuteInSequence() {*
>> > * return false;*
>> > *}*
>> >
>> > As you see in the above, the function, 'getExecuteInSequence', just
>> returns
>> > false instead of getting the value from the global variable.
>> >
>> > And one more change is that the file has been moved to
>> > 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>> >
>> > Am I missing something related with this or do we stop supporting this
>> > option in 4.3?
>> > I'm a little confused, so please help me resolve this.
>> >
>> > Thanks
>> > Alex Ough
>> >
>> >
>> >
>> >
>> > On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
>> wrote:
>> >
>> >> Thanks a lot for your confirmation, Marcus.
>> >> I'll create a review request unless anyone has an objection.
>> >>
>> >> Thanks
>> >> Alex Ough
>> >>
>> >>
>> >> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <shadowsor@gmail.com
>> >wrote:
>> >>
>> >>> I have done parallel KVM migrations without issue, it's "supposed to
>> >>> work". Really I think it's in the same boat as parallel start/stop. It
>> >>> should work, but the config option is there just in case. I think we
>> >>> should add it.
>> >>>
>> >>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>> >>> <ch...@sungard.com> wrote:
>> >>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>> >>> >> 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
>> >>> >
>> >>> > In the case of VMware, the migrate command is executed via the
>> >>> > MigrateVMTask that's part of the VMware SDK (see
>> >>> >
>> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>> >>> >
>> >>> > For VMware, I know that vCenter will queue and process concurrent
>> >>> > requests for migrations. Specifically, it will throttle the
>> migrations
>> >>> > happening, based on it's internal concurrency constraints, but the
>> task
>> >>> > queue will still accept more connections. Obviously the risk are
>> the
>> >>> > VMware layer tasks timing out if it takes too long for the task
>> queue to
>> >>> > complete.
>> >>> >
>> >>> > As for XenServer, it's happening in what appears to be a similar way
>> >>> > (although the source host is the target for the migration API call).
>> >>> >
>> >>> > Check
>> >>> >
>> >>>
>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>> >>> >
>> >>> > I'm not familiar enough with XenServer's concurrency model for
>> >>> > migrations. Any experts know the answer to if it can handle
>> concurrency
>> >>> > in a stable way?
>> >>> >
>> >>> > With KVM, it's obviously executing via the agent. Similarly to
>> >>> > XenServer, I'm not familiar enough to know about concurrent
>> operations.
>> >>> >
>> >>> > So do the HV experts on the list have any opinions about XenServer
>> and
>> >>> > KVM migration concurrency?
>> >>> >
>> >>> > -chip
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>
>>
>>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
It sounds a little scary...
I looked at the history and found these.
8/9/ : file moved to engine by Alex Huang
9/16 : '_mgmtServer.getExecuteInSequence()' changed to
'getExecuteInSequence()' by Alex Huang
Hi Alex Huang,
I'm not sure if you're aware of this, but can you check this for me?
Thanks
Alex Ough
On Wed, Nov 13, 2013 at 11:18 AM, Marcus Sorensen <sh...@gmail.com>wrote:
> I'm not sure. I know in the past when I've seen files change locations
> it has also clobbered updates to that file. Someone branched, did the
> reorganization work, and merged, while in-between the original file
> changed.
>
> On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com> wrote:
> > All,
> >
> > While merging my changes to 4.3 branch, I found that the option,
> > 'execute.in.sequence.hypervisor.commands' is NOT used in Start/Stop/Copy
> > commands in 'VirtualMachineManagerImpl.java' any more as below.
> >
> >
> > *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
> >
> > *protected boolean getExecuteInSequence() {*
> > * return false;*
> > *}*
> >
> > As you see in the above, the function, 'getExecuteInSequence', just
> returns
> > false instead of getting the value from the global variable.
> >
> > And one more change is that the file has been moved to
> > 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
> >
> > Am I missing something related with this or do we stop supporting this
> > option in 4.3?
> > I'm a little confused, so please help me resolve this.
> >
> > Thanks
> > Alex Ough
> >
> >
> >
> >
> > On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com>
> wrote:
> >
> >> Thanks a lot for your confirmation, Marcus.
> >> I'll create a review request unless anyone has an objection.
> >>
> >> Thanks
> >> Alex Ough
> >>
> >>
> >> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <shadowsor@gmail.com
> >wrote:
> >>
> >>> I have done parallel KVM migrations without issue, it's "supposed to
> >>> work". Really I think it's in the same boat as parallel start/stop. It
> >>> should work, but the config option is there just in case. I think we
> >>> should add it.
> >>>
> >>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> >>> <ch...@sungard.com> wrote:
> >>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >>> >> 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
> >>> >
> >>> > In the case of VMware, the migrate command is executed via the
> >>> > MigrateVMTask that's part of the VMware SDK (see
> >>> >
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >>> >
> >>> > For VMware, I know that vCenter will queue and process concurrent
> >>> > requests for migrations. Specifically, it will throttle the
> migrations
> >>> > happening, based on it's internal concurrency constraints, but the
> task
> >>> > queue will still accept more connections. Obviously the risk are the
> >>> > VMware layer tasks timing out if it takes too long for the task
> queue to
> >>> > complete.
> >>> >
> >>> > As for XenServer, it's happening in what appears to be a similar way
> >>> > (although the source host is the target for the migration API call).
> >>> >
> >>> > Check
> >>> >
> >>>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >>> >
> >>> > I'm not familiar enough with XenServer's concurrency model for
> >>> > migrations. Any experts know the answer to if it can handle
> concurrency
> >>> > in a stable way?
> >>> >
> >>> > With KVM, it's obviously executing via the agent. Similarly to
> >>> > XenServer, I'm not familiar enough to know about concurrent
> operations.
> >>> >
> >>> > So do the HV experts on the list have any opinions about XenServer
> and
> >>> > KVM migration concurrency?
> >>> >
> >>> > -chip
> >>> >
> >>> >
> >>>
> >>>
> >>
>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Marcus Sorensen <sh...@gmail.com>.
I'm not sure. I know in the past when I've seen files change locations
it has also clobbered updates to that file. Someone branched, did the
reorganization work, and merged, while in-between the original file
changed.
On Wed, Nov 13, 2013 at 9:21 AM, Alex Ough <al...@sungard.com> wrote:
> All,
>
> While merging my changes to 4.3 branch, I found that the option,
> 'execute.in.sequence.hypervisor.commands' is NOT used in Start/Stop/Copy
> commands in 'VirtualMachineManagerImpl.java' any more as below.
>
>
> *StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
>
> *protected boolean getExecuteInSequence() {*
> * return false;*
> *}*
>
> As you see in the above, the function, 'getExecuteInSequence', just returns
> false instead of getting the value from the global variable.
>
> And one more change is that the file has been moved to
> 'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
>
> Am I missing something related with this or do we stop supporting this
> option in 4.3?
> I'm a little confused, so please help me resolve this.
>
> Thanks
> Alex Ough
>
>
>
>
> On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com> wrote:
>
>> Thanks a lot for your confirmation, Marcus.
>> I'll create a review request unless anyone has an objection.
>>
>> Thanks
>> Alex Ough
>>
>>
>> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <sh...@gmail.com>wrote:
>>
>>> I have done parallel KVM migrations without issue, it's "supposed to
>>> work". Really I think it's in the same boat as parallel start/stop. It
>>> should work, but the config option is there just in case. I think we
>>> should add it.
>>>
>>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>>> <ch...@sungard.com> wrote:
>>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>>> >> 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
>>> >
>>> > In the case of VMware, the migrate command is executed via the
>>> > MigrateVMTask that's part of the VMware SDK (see
>>> > vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>>> >
>>> > For VMware, I know that vCenter will queue and process concurrent
>>> > requests for migrations. Specifically, it will throttle the migrations
>>> > happening, based on it's internal concurrency constraints, but the task
>>> > queue will still accept more connections. Obviously the risk are the
>>> > VMware layer tasks timing out if it takes too long for the task queue to
>>> > complete.
>>> >
>>> > As for XenServer, it's happening in what appears to be a similar way
>>> > (although the source host is the target for the migration API call).
>>> >
>>> > Check
>>> >
>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>>> >
>>> > I'm not familiar enough with XenServer's concurrency model for
>>> > migrations. Any experts know the answer to if it can handle concurrency
>>> > in a stable way?
>>> >
>>> > With KVM, it's obviously executing via the agent. Similarly to
>>> > XenServer, I'm not familiar enough to know about concurrent operations.
>>> >
>>> > So do the HV experts on the list have any opinions about XenServer and
>>> > KVM migration concurrency?
>>> >
>>> > -chip
>>> >
>>> >
>>>
>>>
>>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
All,
While merging my changes to 4.3 branch, I found that the option,
'execute.in.sequence.hypervisor.commands' is NOT used in Start/Stop/Copy
commands in 'VirtualMachineManagerImpl.java' any more as below.
*StopCommand stop = new StopCommand(vm, getExecuteInSequence());*
*protected boolean getExecuteInSequence() {*
* return false;*
*}*
As you see in the above, the function, 'getExecuteInSequence', just returns
false instead of getting the value from the global variable.
And one more change is that the file has been moved to
'engine/orchestration/src/com/cloud/vm' from 'server/src/com/cloud/vm'.
Am I missing something related with this or do we stop supporting this
option in 4.3?
I'm a little confused, so please help me resolve this.
Thanks
Alex Ough
On Tue, Nov 12, 2013 at 4:20 PM, Alex Ough <al...@sungard.com> wrote:
> Thanks a lot for your confirmation, Marcus.
> I'll create a review request unless anyone has an objection.
>
> Thanks
> Alex Ough
>
>
> On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <sh...@gmail.com>wrote:
>
>> I have done parallel KVM migrations without issue, it's "supposed to
>> work". Really I think it's in the same boat as parallel start/stop. It
>> should work, but the config option is there just in case. I think we
>> should add it.
>>
>> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
>> <ch...@sungard.com> wrote:
>> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>> >> 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
>> >
>> > In the case of VMware, the migrate command is executed via the
>> > MigrateVMTask that's part of the VMware SDK (see
>> > vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>> >
>> > For VMware, I know that vCenter will queue and process concurrent
>> > requests for migrations. Specifically, it will throttle the migrations
>> > happening, based on it's internal concurrency constraints, but the task
>> > queue will still accept more connections. Obviously the risk are the
>> > VMware layer tasks timing out if it takes too long for the task queue to
>> > complete.
>> >
>> > As for XenServer, it's happening in what appears to be a similar way
>> > (although the source host is the target for the migration API call).
>> >
>> > Check
>> >
>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>> >
>> > I'm not familiar enough with XenServer's concurrency model for
>> > migrations. Any experts know the answer to if it can handle concurrency
>> > in a stable way?
>> >
>> > With KVM, it's obviously executing via the agent. Similarly to
>> > XenServer, I'm not familiar enough to know about concurrent operations.
>> >
>> > So do the HV experts on the list have any opinions about XenServer and
>> > KVM migration concurrency?
>> >
>> > -chip
>> >
>> >
>>
>>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
Thanks a lot for your confirmation, Marcus.
I'll create a review request unless anyone has an objection.
Thanks
Alex Ough
On Tue, Nov 12, 2013 at 3:37 PM, Marcus Sorensen <sh...@gmail.com>wrote:
> I have done parallel KVM migrations without issue, it's "supposed to
> work". Really I think it's in the same boat as parallel start/stop. It
> should work, but the config option is there just in case. I think we
> should add it.
>
> On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
> <ch...@sungard.com> wrote:
> > On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> >> 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
> >
> > In the case of VMware, the migrate command is executed via the
> > MigrateVMTask that's part of the VMware SDK (see
> > vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
> >
> > For VMware, I know that vCenter will queue and process concurrent
> > requests for migrations. Specifically, it will throttle the migrations
> > happening, based on it's internal concurrency constraints, but the task
> > queue will still accept more connections. Obviously the risk are the
> > VMware layer tasks timing out if it takes too long for the task queue to
> > complete.
> >
> > As for XenServer, it's happening in what appears to be a similar way
> > (although the source host is the target for the migration API call).
> >
> > Check
> >
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
> >
> > I'm not familiar enough with XenServer's concurrency model for
> > migrations. Any experts know the answer to if it can handle concurrency
> > in a stable way?
> >
> > With KVM, it's obviously executing via the agent. Similarly to
> > XenServer, I'm not familiar enough to know about concurrent operations.
> >
> > So do the HV experts on the list have any opinions about XenServer and
> > KVM migration concurrency?
> >
> > -chip
> >
> >
>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Marcus Sorensen <sh...@gmail.com>.
I have done parallel KVM migrations without issue, it's "supposed to
work". Really I think it's in the same boat as parallel start/stop. It
should work, but the config option is there just in case. I think we
should add it.
On Thu, Oct 3, 2013 at 11:41 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
>> 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
>
> In the case of VMware, the migrate command is executed via the
> MigrateVMTask that's part of the VMware SDK (see
> vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
>
> For VMware, I know that vCenter will queue and process concurrent
> requests for migrations. Specifically, it will throttle the migrations
> happening, based on it's internal concurrency constraints, but the task
> queue will still accept more connections. Obviously the risk are the
> VMware layer tasks timing out if it takes too long for the task queue to
> complete.
>
> As for XenServer, it's happening in what appears to be a similar way
> (although the source host is the target for the migration API call).
>
> Check
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
>
> I'm not familiar enough with XenServer's concurrency model for
> migrations. Any experts know the answer to if it can handle concurrency
> in a stable way?
>
> With KVM, it's obviously executing via the agent. Similarly to
> XenServer, I'm not familiar enough to know about concurrent operations.
>
> So do the HV experts on the list have any opinions about XenServer and
> KVM migration concurrency?
>
> -chip
>
>
Re: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Oct 03, 2013 at 11:44:46AM -0500, Alex Ough wrote:
> 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
In the case of VMware, the migrate command is executed via the
MigrateVMTask that's part of the VMware SDK (see
vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java).
For VMware, I know that vCenter will queue and process concurrent
requests for migrations. Specifically, it will throttle the migrations
happening, based on it's internal concurrency constraints, but the task
queue will still accept more connections. Obviously the risk are the
VMware layer tasks timing out if it takes too long for the task queue to
complete.
As for XenServer, it's happening in what appears to be a similar way
(although the source host is the target for the migration API call).
Check
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java.
I'm not familiar enough with XenServer's concurrency model for
migrations. Any experts know the answer to if it can handle concurrency
in a stable way?
With KVM, it's obviously executing via the agent. Similarly to
XenServer, I'm not familiar enough to know about concurrent operations.
So do the HV experts on the list have any opinions about XenServer and
KVM migration concurrency?
-chip
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
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" <ko...@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 <al...@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 <ko...@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
> >>> <ma...@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
> >>> <ma...@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
> >>> <ch...@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<ma...@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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
>
>
>
>
Re: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Alena Prokharchyk <Al...@citrix.com>.
On 10/3/13 9:25 AM, "Koushik Das" <ko...@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 <al...@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 <ko...@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
>>> <ma...@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
>>> <ma...@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
>>> <ch...@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<ma...@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
Re: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Koushik Das <ko...@citrix.com>.
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.
-Koushik
On 03-Oct-2013, at 8:10 PM, Alex Ough <al...@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 <ko...@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
>> <ma...@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
>> <ma...@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
>> <ch...@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<ma...@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
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 <ko...@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
> <ma...@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
> <ma...@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
> <ch...@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<ma...@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
>
>
>
>
>
>
>
>
>
>
Re: A question on vm migrations when hosts are set into a
maintenance mode.
Posted by Koushik Das <ko...@citrix.com>.
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 <al...@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 <sh...@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 <al...@sungard.com>> wrote:
Marcus/Kelven,
Any thoughts on my suggestions?
Thanks
Alex Ough
On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough <al...@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 <sh...@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
<ch...@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 <al...@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<ma...@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
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Alex Ough <al...@sungard.com>.
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 <sh...@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 <al...@sungard.com> wrote:
> > Marcus/Kelven,
> >
> > Any thoughts on my suggestions?
> >
> > Thanks
> > Alex Ough
> >
> >
> > On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough <al...@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 <sh...@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
> >>> <ch...@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 <al...@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>
> >>> >> > 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
> >>> >> >>
> >>> >> >
> >>> >> >
> >>>
> >>
> >
>
>
Re: A question on vm migrations when hosts are set into a maintenance mode.
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <al...@sungard.com> wrote:
> Marcus/Kelven,
>
> Any thoughts on my suggestions?
>
> Thanks
> Alex Ough
>
>
> On Tue, Sep 24, 2013 at 12:09 PM, Alex Ough <al...@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 <sh...@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
>>> <ch...@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 <al...@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 <al...@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
>>> >> >>
>>> >> >
>>> >> >
>>>
>>
>