Hi,
There may be a difference in what you have allocated and what is being actually
used. The dashboard shows what is allocated.
Regards,
Bharat.
On 11/21/16, 9:44 PM, "williamstev...@gmail.com on behalf of Will Stevens"
wrote:
>You will have to contact Accelerite for support with ACP (pre
-2015, at 9:50 am, Bharat Kumar wrote:
> Hi,
>
> The change in cpu overcommit factor will not change the amount of resource
> that are available to you. It will change the way you want to use the free
> resource available at that time. It won’t change
> what was already a
real GHz the overprovisioned amount of GHz (324GHz) as aspected, but
after a while also the sum of Ghz is multiplied by the same factor making
it unnecessary...
Il 21/04/2015 15:26, Bharat Kumar ha scritto:
In case of cloudstack, cpu capacity for host is total of cpus * no of
Ghz * overporvisoning.
In case of cloudstack, cpu capacity for host is total of cpus * no of Ghz *
overporvisoning.
total capacity = sum of capacities of individual hosts.
Thanks,
Bharat.
On 21-Apr-2015, at 6:49 pm, Abhinandan Prateek
wrote:
> Available CPU will be 3 times the actual CPU when over provisioned by
Hi ,
This doc should make the memory calculations clear to you.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
Thanks,
Bharat.
On 16-Apr-2015, at 3:24 pm, 蔡高扬
mailto:caigaoyang...@pingan.com.cn>> wrote:
When I changed the value of “mem.overprovisioning.fac
I am thinking you are using advanced networking, can you check the vlan id
provided while adding the public ip range.
Regards,
Bharat.
On 09-Aug-2014, at 9:32 am, Carlos Reátegui wrote:
> Usually the log entries just before the exception provide some hints as to
> what may have happened
>
>
Hi Jun,
check if host B has the systemvm.iso in it. if not copy it manually from host
A.
cloudstack generally dose this for you when you add a host for the first time.
before adding the host make sure the host tags are cleared.
Regards,
Bharat.
On 10-Mar-2014, at 4:35 pm, Du Jun wrote:
> Hi
Hi,
I see this in the logs.
{"com.cloud.agent.api.check.CheckSshAnswer":{"result":false,"details":"Can not
ping System vm r-9-VMdue to:Unable to
connect","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
by previous
failure","wait":0}},{"com.cloud.agent.api.Answer":{"
capacity checker runs again. During
> first 5 minutes after changes values are correct.
>
>
> On Tue, Oct 15, 2013 at 12:29 PM, Bharat Kumar wrote:
>
>> Hi Valery,
>> you will see incorrect values until the capacity checker runs again. By
>> default i think i
Hi Valery,
you will see incorrect values until the capacity checker runs again. By default
i think it runs every 5 min.
you can change the interval at which capacity checker runs by changing the
capacity.check.period
global config.
-Bharat.
On Oct 15, 2013, at 1:56 PM, Valery Ciareszka
wrot
Hi All,
Added the Function spec at
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Compute+Offering+FS
please go thorough this and give me your comments.
-Bharat.
On Sep 30, 2013, at 12:34 PM, Bharat Kumar wrote:
> Hi All,
>
> Currently in cloudstack we need to
Hi All,
Currently in cloudstack we need to associate every vm with a service offering
and also we cannot specify the size of the root disk when using templates i.e.
we
cannot specify different size of root disks while using the same template.
I would like to propose a feature to allow VM creat
ng settings. Less ideally, one should more
> easily change the settings for (default) system service offerings. A
> "Default" checkbox in the edit form would be nice :)
>
> Regards,
> Dinu
>
>
>
> On Aug 22, 2013, at 8:55 AM, Bharat Kumar wrote:
>
>
Hi Dinu,
you can modify the system service offering for the systems vms and change it to
512MB so that when using overcommit (of 4 ) its memory is set to 128 MB.
you are right the current memory is set to system offering divided by the over
provisioning factor.
On Aug 22, 2013, at 2:05 AM,
ant.
>
> Well, do you have something to share how to avoid the contention for VM1 and
> vm2?
>
> I propose a solution that during 9-10am stopped VM1, running vm2
> During 10-11am,stopped vm2 and running vm1
>
> Thanks
> Jerry
>
>
>
> Jerry
>
>
Hi jiri,
The actual utilization can never be greater than 400% i.e. 100% per vCPu. we
are overcommitting by allocating 4 vCpus to both the VMs. if both the VMs are
trying to use what is allocated then
there will be contention for resources. During the contention the resource
allocation is d
16 matches
Mail list logo
