cc Alex Huang to get his attention:
On Nov 15, 2013, at 10:17 PM, Prasanna Santhanam <t...@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 <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
>
