You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Jeronimo Garcia <ga...@gmail.com> on 2013/04/04 20:36:19 UTC

Job-Executor workers

Hi List.

I'm having issues when deploying a big number of virtual machines across a
number of nodes.

the imporession that i get ( from the logs) is that the AsyncJobExecutor is
pulling jobs from the queue and do them one by one (which when you are
deploying a big number of virtual machines could take a long while)

In AsyncJobManager.java i see something that could change this behaviour
but im not sure:

*final int cloudMaxActive =
Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
                       *
*int poolSize = (cloudMaxActive * 2) / 3;*

.

I'm using 'random' as vm.allocation.algorithm , and my rest is to deploy
200 vms across 7 nodes using local storage, also im using
cloud-server-4.0.1-1 version.

I've tried playing with worker settings in agents and manager but i don't
see any change so far.

Thanks!

Re: Job-Executor workers

Posted by Kelven Yang <ke...@citrix.com>.
Most of commands are executed in sequence at per-host scope, there will be
some concurrency when VMs are being deployed among different hosts.
However, for each individual orchestration flow, concurrency is usually
not in consideration in current code base.

Kelven


On 4/4/13 12:39 PM, "Jeronimo Garcia" <ga...@gmail.com> wrote:

>Ok I'll rebuild and see the differences and wether we want to have this
>live or not .
>
>Thanks a lot for your help!
>
>
>On Thu, Apr 4, 2013 at 2:23 PM, Alena Prokharchyk <
>Alena.Prokharchyk@citrix.com> wrote:
>
>> No, it can't be updated using UI/WebServices APIs.
>>
>> I remember somebody in the dev list mentioned that he modified
>> StartCommand.java with executeInSequence=false and tested it with KVM
>> hypervisor, and it worked for him. Not sure how concurrent starts (and
>>how
>> many) are supported by other hypervisors, so have to be careful if
>>decide
>> to set this flag to true.
>>
>>
>>
>>
>> On 4/4/13 12:01 PM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
>>
>> >Hi.
>> >
>> >I can see the override on *agent/api/StartCommand.java*
>> >*
>> >*
>> >*@Override*
>> >*public boolean executeInSequence() {*
>> >*      return true;
>> >                                                           *
>> >*}*
>> >*
>> >*
>> >I'm guessing this can't be changed from the gui or api right?
>> >
>> >Thanks
>> >
>> >
>> >On Thu, Apr 4, 2013 at 1:56 PM, Jeronimo Garcia
>> ><ga...@gmail.com>wrote:
>> >
>> >> Thanks Alena, im checking that out now.
>> >> Chiradeep , I'm using the default centos template that comes with the
>> >> secondary storage sys vm.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> On Thu, Apr 4, 2013 at 1:53 PM, Chiradeep Vittal <
>> >> Chiradeep.Vittal@citrix.com> wrote:
>> >>
>> >>> Note that each deployment to local storage has to download the base
>> >>> template to local disk from secondary storage. How big is the
>>template?
>> >>> How fast is your secondary storage?
>> >>>
>> >>>
>> >>> On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
>> >>>
>> >>> >Hi List.
>> >>> >
>> >>> >I'm having issues when deploying a big number of virtual machines
>> >>>across
>> >>> a
>> >>> >number of nodes.
>> >>> >
>> >>> >the imporession that i get ( from the logs) is that the
>> >>>AsyncJobExecutor
>> >>> >is
>> >>> >pulling jobs from the queue and do them one by one (which when you
>>are
>> >>> >deploying a big number of virtual machines could take a long while)
>> >>> >
>> >>> >In AsyncJobManager.java i see something that could change this
>> >>>behaviour
>> >>> >but im not sure:
>> >>> >
>> >>> >*final int cloudMaxActive =
>> >>> >Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
>> >>> >                       *
>> >>> >*int poolSize = (cloudMaxActive * 2) / 3;*
>> >>> >
>> >>> >.
>> >>> >
>> >>> >I'm using 'random' as vm.allocation.algorithm , and my rest is to
>> >>>deploy
>> >>> >200 vms across 7 nodes using local storage, also im using
>> >>> >cloud-server-4.0.1-1 version.
>> >>> >
>> >>> >I've tried playing with worker settings in agents and manager but i
>> >>>don't
>> >>> >see any change so far.
>> >>> >
>> >>> >Thanks!
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>


Re: Job-Executor workers

Posted by Nguyen Anh Tu <ng...@gmail.com>.
sorry. executeInSequence=false


2013/5/29 Nguyen Anh Tu <ng...@gmail.com>

> I just changed StartCommand.java with executeInSequence=true and tested it
> with Xen XCP 1.1. The speed was enhanced beatifully.
>
> Thanks.
>
>
> 2013/4/5 Jeronimo Garcia <ga...@gmail.com>
>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-1940
>>
>> Thank you all.
>>
>>
>> On Thu, Apr 4, 2013 at 3:15 PM, Jeronimo Garcia <garciaj.uk@gmail.com
>> >wrote:
>>
>> > Hi All.
>> >
>> > Thanks for the help .
>> >
>> > I'll be trying to fill a bug about this today/tomorrow.
>> >
>> > Thanks Again
>> >
>> >
>> > On Thu, Apr 4, 2013 at 3:12 PM, Chip Childers <
>> chip.childers@sungard.com>wrote:
>> >
>> >> On Thu, Apr 04, 2013 at 01:09:00PM -0700, Alex Huang wrote:
>> >> > Jeronimo,
>> >> >
>> >> > Do you mind filing a bug for this?
>> >> >
>> >> > There's some legacy with this that went all the way back to 1.0 of
>> our
>> >> product.  Back then, multiple commands executing on the same
>> hypervisor was
>> >> just not very reliable.  Xen 3 would sometimes brick when multiple vm
>> >> commands were executed.  I doubt it's necessary any more but we need
>> to do
>> >> some tests before we can remove this.
>> >> >
>> >> > I've heard of this type of requests from others as well so a bug
>> would
>> >> be good to track this.
>> >>
>> >> Yeah, Ilya and Kelcey were asking about it around VMware.
>> >>
>> >>
>> >
>>
>
>
>
> --
>
> N.g.U.y.e.N.A.n.H.t.U
>



-- 

N.g.U.y.e.N.A.n.H.t.U

Re: Job-Executor workers

Posted by Nguyen Anh Tu <ng...@gmail.com>.
I just changed StartCommand.java with executeInSequence=true and tested it
with Xen XCP 1.1. The speed was enhanced beatifully.

Thanks.


2013/4/5 Jeronimo Garcia <ga...@gmail.com>

> https://issues.apache.org/jira/browse/CLOUDSTACK-1940
>
> Thank you all.
>
>
> On Thu, Apr 4, 2013 at 3:15 PM, Jeronimo Garcia <garciaj.uk@gmail.com
> >wrote:
>
> > Hi All.
> >
> > Thanks for the help .
> >
> > I'll be trying to fill a bug about this today/tomorrow.
> >
> > Thanks Again
> >
> >
> > On Thu, Apr 4, 2013 at 3:12 PM, Chip Childers <chip.childers@sungard.com
> >wrote:
> >
> >> On Thu, Apr 04, 2013 at 01:09:00PM -0700, Alex Huang wrote:
> >> > Jeronimo,
> >> >
> >> > Do you mind filing a bug for this?
> >> >
> >> > There's some legacy with this that went all the way back to 1.0 of our
> >> product.  Back then, multiple commands executing on the same hypervisor
> was
> >> just not very reliable.  Xen 3 would sometimes brick when multiple vm
> >> commands were executed.  I doubt it's necessary any more but we need to
> do
> >> some tests before we can remove this.
> >> >
> >> > I've heard of this type of requests from others as well so a bug would
> >> be good to track this.
> >>
> >> Yeah, Ilya and Kelcey were asking about it around VMware.
> >>
> >>
> >
>



-- 

N.g.U.y.e.N.A.n.H.t.U

Re: Job-Executor workers

Posted by Jeronimo Garcia <ga...@gmail.com>.
https://issues.apache.org/jira/browse/CLOUDSTACK-1940

Thank you all.


On Thu, Apr 4, 2013 at 3:15 PM, Jeronimo Garcia <ga...@gmail.com>wrote:

> Hi All.
>
> Thanks for the help .
>
> I'll be trying to fill a bug about this today/tomorrow.
>
> Thanks Again
>
>
> On Thu, Apr 4, 2013 at 3:12 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Thu, Apr 04, 2013 at 01:09:00PM -0700, Alex Huang wrote:
>> > Jeronimo,
>> >
>> > Do you mind filing a bug for this?
>> >
>> > There's some legacy with this that went all the way back to 1.0 of our
>> product.  Back then, multiple commands executing on the same hypervisor was
>> just not very reliable.  Xen 3 would sometimes brick when multiple vm
>> commands were executed.  I doubt it's necessary any more but we need to do
>> some tests before we can remove this.
>> >
>> > I've heard of this type of requests from others as well so a bug would
>> be good to track this.
>>
>> Yeah, Ilya and Kelcey were asking about it around VMware.
>>
>>
>

Re: Job-Executor workers

Posted by Jeronimo Garcia <ga...@gmail.com>.
Hi All.

Thanks for the help .

I'll be trying to fill a bug about this today/tomorrow.

Thanks Again


On Thu, Apr 4, 2013 at 3:12 PM, Chip Childers <ch...@sungard.com>wrote:

> On Thu, Apr 04, 2013 at 01:09:00PM -0700, Alex Huang wrote:
> > Jeronimo,
> >
> > Do you mind filing a bug for this?
> >
> > There's some legacy with this that went all the way back to 1.0 of our
> product.  Back then, multiple commands executing on the same hypervisor was
> just not very reliable.  Xen 3 would sometimes brick when multiple vm
> commands were executed.  I doubt it's necessary any more but we need to do
> some tests before we can remove this.
> >
> > I've heard of this type of requests from others as well so a bug would
> be good to track this.
>
> Yeah, Ilya and Kelcey were asking about it around VMware.
>
>

Re: Job-Executor workers

Posted by Chip Childers <ch...@sungard.com>.
On Thu, Apr 04, 2013 at 01:09:00PM -0700, Alex Huang wrote:
> Jeronimo,
> 
> Do you mind filing a bug for this?  
> 
> There's some legacy with this that went all the way back to 1.0 of our product.  Back then, multiple commands executing on the same hypervisor was just not very reliable.  Xen 3 would sometimes brick when multiple vm commands were executed.  I doubt it's necessary any more but we need to do some tests before we can remove this.
> 
> I've heard of this type of requests from others as well so a bug would be good to track this.

Yeah, Ilya and Kelcey were asking about it around VMware.


RE: Job-Executor workers

Posted by Alex Huang <Al...@citrix.com>.
Jeronimo,

Do you mind filing a bug for this?  

There's some legacy with this that went all the way back to 1.0 of our product.  Back then, multiple commands executing on the same hypervisor was just not very reliable.  Xen 3 would sometimes brick when multiple vm commands were executed.  I doubt it's necessary any more but we need to do some tests before we can remove this.

I've heard of this type of requests from others as well so a bug would be good to track this.

Thanks.

--Alex

> -----Original Message-----
> From: Jeronimo Garcia [mailto:garciaj.uk@gmail.com]
> Sent: Thursday, April 4, 2013 12:40 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Job-Executor workers
> 
> Ok I'll rebuild and see the differences and wether we want to have this live
> or not .
> 
> Thanks a lot for your help!
> 
> 
> On Thu, Apr 4, 2013 at 2:23 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
> 
> > No, it can't be updated using UI/WebServices APIs.
> >
> > I remember somebody in the dev list mentioned that he modified
> > StartCommand.java with executeInSequence=false and tested it with KVM
> > hypervisor, and it worked for him. Not sure how concurrent starts (and
> > how
> > many) are supported by other hypervisors, so have to be careful if
> > decide to set this flag to true.
> >
> >
> >
> >
> > On 4/4/13 12:01 PM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
> >
> > >Hi.
> > >
> > >I can see the override on *agent/api/StartCommand.java*
> > >*
> > >*
> > >*@Override*
> > >*public boolean executeInSequence() {*
> > >*      return true;
> > >                                                           *
> > >*}*
> > >*
> > >*
> > >I'm guessing this can't be changed from the gui or api right?
> > >
> > >Thanks
> > >
> > >
> > >On Thu, Apr 4, 2013 at 1:56 PM, Jeronimo Garcia
> > ><ga...@gmail.com>wrote:
> > >
> > >> Thanks Alena, im checking that out now.
> > >> Chiradeep , I'm using the default centos template that comes with
> > >> the secondary storage sys vm.
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> On Thu, Apr 4, 2013 at 1:53 PM, Chiradeep Vittal <
> > >> Chiradeep.Vittal@citrix.com> wrote:
> > >>
> > >>> Note that each deployment to local storage has to download the
> > >>> base template to local disk from secondary storage. How big is the
> template?
> > >>> How fast is your secondary storage?
> > >>>
> > >>>
> > >>> On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
> > >>>
> > >>> >Hi List.
> > >>> >
> > >>> >I'm having issues when deploying a big number of virtual machines
> > >>>across
> > >>> a
> > >>> >number of nodes.
> > >>> >
> > >>> >the imporession that i get ( from the logs) is that the
> > >>>AsyncJobExecutor
> > >>> >is
> > >>> >pulling jobs from the queue and do them one by one (which when
> > >>> >you are deploying a big number of virtual machines could take a
> > >>> >long while)
> > >>> >
> > >>> >In AsyncJobManager.java i see something that could change this
> > >>>behaviour
> > >>> >but im not sure:
> > >>> >
> > >>> >*final int cloudMaxActive =
> > >>> >Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
> > >>> >                       *
> > >>> >*int poolSize = (cloudMaxActive * 2) / 3;*
> > >>> >
> > >>> >.
> > >>> >
> > >>> >I'm using 'random' as vm.allocation.algorithm , and my rest is to
> > >>>deploy
> > >>> >200 vms across 7 nodes using local storage, also im using
> > >>> >cloud-server-4.0.1-1 version.
> > >>> >
> > >>> >I've tried playing with worker settings in agents and manager but
> > >>> >i
> > >>>don't
> > >>> >see any change so far.
> > >>> >
> > >>> >Thanks!
> > >>>
> > >>>
> > >>
> > >
> >
> >
> >

RE: Job-Executor workers

Posted by Alex Huang <Al...@citrix.com>.

> -----Original Message-----
> From: Alex Huang
> Sent: Thursday, April 4, 2013 1:09 PM
> To: dev@cloudstack.apache.org
> Subject: RE: Job-Executor workers
> 
> Jeronimo,
> 
> Do you mind filing a bug for this?
> 
> There's some legacy with this that went all the way back to 1.0 of our product.

Duh...that was big slip there.  Back to 1.0 of Cloudstack which was not an open source project.

--Alex


Re: Job-Executor workers

Posted by Jeronimo Garcia <ga...@gmail.com>.
Ok I'll rebuild and see the differences and wether we want to have this
live or not .

Thanks a lot for your help!


On Thu, Apr 4, 2013 at 2:23 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> No, it can't be updated using UI/WebServices APIs.
>
> I remember somebody in the dev list mentioned that he modified
> StartCommand.java with executeInSequence=false and tested it with KVM
> hypervisor, and it worked for him. Not sure how concurrent starts (and how
> many) are supported by other hypervisors, so have to be careful if decide
> to set this flag to true.
>
>
>
>
> On 4/4/13 12:01 PM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
>
> >Hi.
> >
> >I can see the override on *agent/api/StartCommand.java*
> >*
> >*
> >*@Override*
> >*public boolean executeInSequence() {*
> >*      return true;
> >                                                           *
> >*}*
> >*
> >*
> >I'm guessing this can't be changed from the gui or api right?
> >
> >Thanks
> >
> >
> >On Thu, Apr 4, 2013 at 1:56 PM, Jeronimo Garcia
> ><ga...@gmail.com>wrote:
> >
> >> Thanks Alena, im checking that out now.
> >> Chiradeep , I'm using the default centos template that comes with the
> >> secondary storage sys vm.
> >>
> >> Thanks!
> >>
> >>
> >> On Thu, Apr 4, 2013 at 1:53 PM, Chiradeep Vittal <
> >> Chiradeep.Vittal@citrix.com> wrote:
> >>
> >>> Note that each deployment to local storage has to download the base
> >>> template to local disk from secondary storage. How big is the template?
> >>> How fast is your secondary storage?
> >>>
> >>>
> >>> On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
> >>>
> >>> >Hi List.
> >>> >
> >>> >I'm having issues when deploying a big number of virtual machines
> >>>across
> >>> a
> >>> >number of nodes.
> >>> >
> >>> >the imporession that i get ( from the logs) is that the
> >>>AsyncJobExecutor
> >>> >is
> >>> >pulling jobs from the queue and do them one by one (which when you are
> >>> >deploying a big number of virtual machines could take a long while)
> >>> >
> >>> >In AsyncJobManager.java i see something that could change this
> >>>behaviour
> >>> >but im not sure:
> >>> >
> >>> >*final int cloudMaxActive =
> >>> >Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
> >>> >                       *
> >>> >*int poolSize = (cloudMaxActive * 2) / 3;*
> >>> >
> >>> >.
> >>> >
> >>> >I'm using 'random' as vm.allocation.algorithm , and my rest is to
> >>>deploy
> >>> >200 vms across 7 nodes using local storage, also im using
> >>> >cloud-server-4.0.1-1 version.
> >>> >
> >>> >I've tried playing with worker settings in agents and manager but i
> >>>don't
> >>> >see any change so far.
> >>> >
> >>> >Thanks!
> >>>
> >>>
> >>
> >
>
>
>

Re: Job-Executor workers

Posted by Alena Prokharchyk <Al...@citrix.com>.
No, it can't be updated using UI/WebServices APIs.

I remember somebody in the dev list mentioned that he modified
StartCommand.java with executeInSequence=false and tested it with KVM
hypervisor, and it worked for him. Not sure how concurrent starts (and how
many) are supported by other hypervisors, so have to be careful if decide
to set this flag to true.




On 4/4/13 12:01 PM, "Jeronimo Garcia" <ga...@gmail.com> wrote:

>Hi.
>
>I can see the override on *agent/api/StartCommand.java*
>*
>*
>*@Override*
>*public boolean executeInSequence() {*
>*      return true;
>                                                           *
>*}*
>*
>*
>I'm guessing this can't be changed from the gui or api right?
>
>Thanks
>
>
>On Thu, Apr 4, 2013 at 1:56 PM, Jeronimo Garcia
><ga...@gmail.com>wrote:
>
>> Thanks Alena, im checking that out now.
>> Chiradeep , I'm using the default centos template that comes with the
>> secondary storage sys vm.
>>
>> Thanks!
>>
>>
>> On Thu, Apr 4, 2013 at 1:53 PM, Chiradeep Vittal <
>> Chiradeep.Vittal@citrix.com> wrote:
>>
>>> Note that each deployment to local storage has to download the base
>>> template to local disk from secondary storage. How big is the template?
>>> How fast is your secondary storage?
>>>
>>>
>>> On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
>>>
>>> >Hi List.
>>> >
>>> >I'm having issues when deploying a big number of virtual machines
>>>across
>>> a
>>> >number of nodes.
>>> >
>>> >the imporession that i get ( from the logs) is that the
>>>AsyncJobExecutor
>>> >is
>>> >pulling jobs from the queue and do them one by one (which when you are
>>> >deploying a big number of virtual machines could take a long while)
>>> >
>>> >In AsyncJobManager.java i see something that could change this
>>>behaviour
>>> >but im not sure:
>>> >
>>> >*final int cloudMaxActive =
>>> >Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
>>> >                       *
>>> >*int poolSize = (cloudMaxActive * 2) / 3;*
>>> >
>>> >.
>>> >
>>> >I'm using 'random' as vm.allocation.algorithm , and my rest is to
>>>deploy
>>> >200 vms across 7 nodes using local storage, also im using
>>> >cloud-server-4.0.1-1 version.
>>> >
>>> >I've tried playing with worker settings in agents and manager but i
>>>don't
>>> >see any change so far.
>>> >
>>> >Thanks!
>>>
>>>
>>
>



Re: Job-Executor workers

Posted by Jeronimo Garcia <ga...@gmail.com>.
Hi.

I can see the override on *agent/api/StartCommand.java*
*
*
*@Override*
*public boolean executeInSequence() {*
*      return true;
                                                           *
*}*
*
*
I'm guessing this can't be changed from the gui or api right?

Thanks


On Thu, Apr 4, 2013 at 1:56 PM, Jeronimo Garcia <ga...@gmail.com>wrote:

> Thanks Alena, im checking that out now.
> Chiradeep , I'm using the default centos template that comes with the
> secondary storage sys vm.
>
> Thanks!
>
>
> On Thu, Apr 4, 2013 at 1:53 PM, Chiradeep Vittal <
> Chiradeep.Vittal@citrix.com> wrote:
>
>> Note that each deployment to local storage has to download the base
>> template to local disk from secondary storage. How big is the template?
>> How fast is your secondary storage?
>>
>>
>> On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
>>
>> >Hi List.
>> >
>> >I'm having issues when deploying a big number of virtual machines across
>> a
>> >number of nodes.
>> >
>> >the imporession that i get ( from the logs) is that the AsyncJobExecutor
>> >is
>> >pulling jobs from the queue and do them one by one (which when you are
>> >deploying a big number of virtual machines could take a long while)
>> >
>> >In AsyncJobManager.java i see something that could change this behaviour
>> >but im not sure:
>> >
>> >*final int cloudMaxActive =
>> >Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
>> >                       *
>> >*int poolSize = (cloudMaxActive * 2) / 3;*
>> >
>> >.
>> >
>> >I'm using 'random' as vm.allocation.algorithm , and my rest is to deploy
>> >200 vms across 7 nodes using local storage, also im using
>> >cloud-server-4.0.1-1 version.
>> >
>> >I've tried playing with worker settings in agents and manager but i don't
>> >see any change so far.
>> >
>> >Thanks!
>>
>>
>

Re: Job-Executor workers

Posted by Jeronimo Garcia <ga...@gmail.com>.
Thanks Alena, im checking that out now.
Chiradeep , I'm using the default centos template that comes with the
secondary storage sys vm.

Thanks!


On Thu, Apr 4, 2013 at 1:53 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:

> Note that each deployment to local storage has to download the base
> template to local disk from secondary storage. How big is the template?
> How fast is your secondary storage?
>
>
> On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:
>
> >Hi List.
> >
> >I'm having issues when deploying a big number of virtual machines across a
> >number of nodes.
> >
> >the imporession that i get ( from the logs) is that the AsyncJobExecutor
> >is
> >pulling jobs from the queue and do them one by one (which when you are
> >deploying a big number of virtual machines could take a long while)
> >
> >In AsyncJobManager.java i see something that could change this behaviour
> >but im not sure:
> >
> >*final int cloudMaxActive =
> >Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
> >                       *
> >*int poolSize = (cloudMaxActive * 2) / 3;*
> >
> >.
> >
> >I'm using 'random' as vm.allocation.algorithm , and my rest is to deploy
> >200 vms across 7 nodes using local storage, also im using
> >cloud-server-4.0.1-1 version.
> >
> >I've tried playing with worker settings in agents and manager but i don't
> >see any change so far.
> >
> >Thanks!
>
>

Re: Job-Executor workers

Posted by Alena Prokharchyk <Al...@citrix.com>.
Hi Jeronimo,

The StartCommands for the Virtual machine are executed sequentially by the
agent. This behavior is set as "executeInSequence" flag on the command
level.

You might look at the Command abstract class (StartCommand extends it) to
see how it works. But basically if this flag is set to true for the
command, it's been queued on per Agent(Host) basis.

-Alena.


On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:

>Hi List.
>
>I'm having issues when deploying a big number of virtual machines across a
>number of nodes.
>
>the imporession that i get ( from the logs) is that the AsyncJobExecutor
>is
>pulling jobs from the queue and do them one by one (which when you are
>deploying a big number of virtual machines could take a long while)
>
>In AsyncJobManager.java i see something that could change this behaviour
>but im not sure:
>
>*final int cloudMaxActive =
>Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
>                       *
>*int poolSize = (cloudMaxActive * 2) / 3;*
>
>.
>
>I'm using 'random' as vm.allocation.algorithm , and my rest is to deploy
>200 vms across 7 nodes using local storage, also im using
>cloud-server-4.0.1-1 version.
>
>I've tried playing with worker settings in agents and manager but i don't
>see any change so far.
>
>Thanks!
>



Re: Job-Executor workers

Posted by Chiradeep Vittal <Ch...@citrix.com>.
Note that each deployment to local storage has to download the base
template to local disk from secondary storage. How big is the template?
How fast is your secondary storage?


On 4/4/13 11:36 AM, "Jeronimo Garcia" <ga...@gmail.com> wrote:

>Hi List.
>
>I'm having issues when deploying a big number of virtual machines across a
>number of nodes.
>
>the imporession that i get ( from the logs) is that the AsyncJobExecutor
>is
>pulling jobs from the queue and do them one by one (which when you are
>deploying a big number of virtual machines could take a long while)
>
>In AsyncJobManager.java i see something that could change this behaviour
>but im not sure:
>
>*final int cloudMaxActive =
>Integer.parseInt(dbProps.getProperty("db.cloud.maxActive"));
>                       *
>*int poolSize = (cloudMaxActive * 2) / 3;*
>
>.
>
>I'm using 'random' as vm.allocation.algorithm , and my rest is to deploy
>200 vms across 7 nodes using local storage, also im using
>cloud-server-4.0.1-1 version.
>
>I've tried playing with worker settings in agents and manager but i don't
>see any change so far.
>
>Thanks!