I see. Thanks for the information, Alex. Alex Ough
On Thu, Nov 21, 2013 at 9:22 AM, Alex Huang <alex.hu...@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.o...@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 <alex.hu...@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.o...@sungard.com <alex.o...@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 <run...@gmail.com> > wrote: > > 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 > > > > > > >
