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 <alex.o...@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.o...@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
> >> <shadow...@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.o...@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.o...@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 <shadow...@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
> >>> >>> <chip.child...@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
