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 <alex.o...@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.hu...@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.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 >> > >> >> >> >> >> > >
