Re: Fault percentage value of CPU usage in Cloud Platform

[Bharat Kumar]

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 (previously CCP).
>We have no visibility into the ACP code or how to support you.
>
>https://support.accelerite.com/hc/en-us
>
>Best of luck...
>
>*Will STEVENS*
>Lead Developer
>
>
>
>On Mon, Nov 21, 2016 at 3:44 AM, anil lakineni <
>anilkumar459.lakin...@gmail.com> wrote:
>
>> Dear All,
>>
>> On CloudPlatform dashboard our CPU usage is showing wrong (high -91%) value
>> which in-turn not allowing us to provision new VMs. But, the fact is only
>> 40% of the available CPU is utilized and Even in the Dashboard only
>> percentage calculation is showing false metric value, But Cpu usage value
>> is showing accurate(800/2000 GHZ).
>>
>> In addition to that when we go to check the CPU status at Zones level we
>> are seeing the accurate CPU usage percentage in all Zones, Only we are
>> getting false usage percentage at dashboard level(which leads to fail the
>> new deployments).
>>
>> - Our CCP version is 4.5.0
>> - Hypervisors are Xen 6.2 & 6.5
>>
>> Please help me to sort out this issue and also let me know if any
>> additional information needed.
>>
>>
>> Best Regards,
>> Anil.
>>




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: cpu overprovisioning

[Bharat Kumar]

Also In case of change in the overcommit value the total capacity will change 
instantaneously, but the used resource and the total available will change when
the capacity checker thread runs. The interval at which this will run can be 
changed from the global settings.

Thanks,
Bharat.

On 22-Apr-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 allocated.
> 
> for example if you have deployed the VMs with overcommit say 2  and after a 
> while you change the overcommit to 3, the used resource will be scaled based 
> on the change.
> changing the overcommit cannot create resource. It can only change the way 
> you want to use the free resource.  So now after the change in overcommit you 
> can deploy 3 times more VMs (of
> a given service offering) than usual using the the resource that is free at 
> the time of changing the overcommit value. The perviously allocated resource 
> cannot be freed until you
> restart the VMs.
> 
> This link will tell you how resource allocation calculations are made.
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit
> 
> Thanks,
> Bharat.
> 
> 
> On 21-Apr-2015, at 11:20 pm, Rafael Weingärtner 
> mailto:rafaelweingart...@gmail.com>> wrote:
> 
> I have not looked at the code, but that seems odd.
> Restarting VMs instances to update the resource usage/resource availability
> when changing the overprovisioning factor.
> 
> On Tue, Apr 21, 2015 at 12:51 PM, S. Brüseke - proIO GmbH <
> s.brues...@proio.com<mailto:s.brues...@proio.com>> wrote:
> 
> Please try to stop and start the vm. Maybe reboot is not working here. You
> should start to see more free CPU after the first vm.
> 
> Mit freundlichen Grüßen / With kind regards,
> 
> Swen Brüseke
> 
> -Ursprüngliche Nachricht-
> Von: Ugo Vasi [mailto:ugo.v...@procne.it]
> Gesendet: Dienstag, 21. April 2015 16:40
> An: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
> Betreff: Re: AW: cpu overprovisioning
> 
> Hi Swen,
> I try rebboting 2 vm but the amount of cpu MHz is not changed. Do I have
> to restart all vm before you see a change?
> 
> 
> Il 21/04/2015 16:16, S. Brüseke - proIO GmbH ha scritto:
> This is because the factor of overprovisioning is attached to the
> instance too! And this factor is only changing after rebooting the instance.
> So after a change of cpu.overprovisioning.factor you need to reboot all
> instances on this cluster which were running before this change was made.
> 
> Mit freundlichen Grüßen / With kind regards,
> 
> Swen Brüseke
> 
> -Ursprüngliche Nachricht-
> Von: Ugo Vasi [mailto:ugo.v...@procne.it]
> Gesendet: Dienstag, 21. April 2015 16:06
> An: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
> Betreff: Re: cpu overprovisioning
> 
> If I change the over-provisioning ratio in cluster-relative settings
> (infrastructure->cluser->cluster-name->settings) the dashboard show the
> sum of 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.
> 
> total capacity = sum of capacities of individual hosts.
> 
> Thanks,
> Bharat.
> 
> On 21-Apr-2015, at 6:49 pm, Abhinandan Prateek <
> abhinandan.prat...@shapeblue.com<mailto:abhinandan.prat...@shapeblue.com>> 
> wrote:
> 
> Available CPU will be 3 times the actual CPU when over provisioned by
> 3.
> 
> The UI not showing the over provisioned value seems like a bug.
> 
> -abhi
> 
> 
> On 21-Apr-2015, at 6:34 pm, Ugo Vasi 
> mailto:ugo.v...@procne.it>> wrote:
> 
> Hi all,
> we have a cluster of three machines with 16 CPU at 2.2GHz each and we
> have set a cpu-overprovizioning to 3.
> 
> I would expect that the CPU system capacity of the dashboard appear
> with the sum of megahertz CPUs multiplied by three instead I get the real
> sum (108MHz).
> 
> I do not understand if this overprovisioning allows me to allocate
> more MHz of real ones asthe documentation say since in reality the virtual
> machines occupy on average only 20% of the computing power.
> 
> thanks in advance
> 
> --
> 
> U g o   V a s imailto:ugo.v...@procne.it>>
> P r o c n e  s.r.l>)
> via Cotonificio 45  33010 Tavagnacc

Re: cpu overprovisioning

[Bharat Kumar]

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 allocated.

for example if you have deployed the VMs with overcommit say 2  and after a 
while you change the overcommit to 3, the used resource will be scaled based on 
the change.
changing the overcommit cannot create resource. It can only change the way you 
want to use the free resource.  So now after the change in overcommit you can 
deploy 3 times more VMs (of
a given service offering) than usual using the the resource that is free at the 
time of changing the overcommit value. The perviously allocated resource cannot 
be freed until you
restart the VMs.

This link will tell you how resource allocation calculations are made.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcommit

Thanks,
Bharat.


On 21-Apr-2015, at 11:20 pm, Rafael Weingärtner 
mailto:rafaelweingart...@gmail.com>> wrote:

I have not looked at the code, but that seems odd.
Restarting VMs instances to update the resource usage/resource availability
when changing the overprovisioning factor.

On Tue, Apr 21, 2015 at 12:51 PM, S. Brüseke - proIO GmbH <
s.brues...@proio.com<mailto:s.brues...@proio.com>> wrote:

Please try to stop and start the vm. Maybe reboot is not working here. You
should start to see more free CPU after the first vm.

Mit freundlichen Grüßen / With kind regards,

Swen Brüseke

-Ursprüngliche Nachricht-
Von: Ugo Vasi [mailto:ugo.v...@procne.it]
Gesendet: Dienstag, 21. April 2015 16:40
An: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Betreff: Re: AW: cpu overprovisioning

Hi Swen,
I try rebboting 2 vm but the amount of cpu MHz is not changed. Do I have
to restart all vm before you see a change?


Il 21/04/2015 16:16, S. Brüseke - proIO GmbH ha scritto:
This is because the factor of overprovisioning is attached to the
instance too! And this factor is only changing after rebooting the instance.
So after a change of cpu.overprovisioning.factor you need to reboot all
instances on this cluster which were running before this change was made.

Mit freundlichen Grüßen / With kind regards,

Swen Brüseke

-Ursprüngliche Nachricht-
Von: Ugo Vasi [mailto:ugo.v...@procne.it]
Gesendet: Dienstag, 21. April 2015 16:06
An: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Betreff: Re: cpu overprovisioning

If I change the over-provisioning ratio in cluster-relative settings
(infrastructure->cluser->cluster-name->settings) the dashboard show the
sum of 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.

total capacity = sum of capacities of individual hosts.

Thanks,
Bharat.

On 21-Apr-2015, at 6:49 pm, Abhinandan Prateek <
abhinandan.prat...@shapeblue.com<mailto:abhinandan.prat...@shapeblue.com>> 
wrote:

Available CPU will be 3 times the actual CPU when over provisioned by
3.

The UI not showing the over provisioned value seems like a bug.

-abhi


On 21-Apr-2015, at 6:34 pm, Ugo Vasi 
mailto:ugo.v...@procne.it>> wrote:

Hi all,
we have a cluster of three machines with 16 CPU at 2.2GHz each and we
have set a cpu-overprovizioning to 3.

I would expect that the CPU system capacity of the dashboard appear
with the sum of megahertz CPUs multiplied by three instead I get the real
sum (108MHz).

I do not understand if this overprovisioning allows me to allocate
more MHz of real ones asthe documentation say since in reality the virtual
machines occupy on average only 20% of the computing power.

thanks in advance

--

U g o   V a s imailto:ugo.v...@procne.it>>
P r o c n e  s.r.l>)
via Cotonificio 45  33010 Tavagnacco IT
phone: +390432486523 fax: +390432486523

Le informazioni contenute in questo messaggio sono riservate e
confidenziali ed è vietata la diffusione in qualunque modo eseguita.
Qualora Lei non fosse la persona a cui il presente messaggio è
destinato, La invitiamo ad eliminarlo e a non leggerlo, dandocene
gentilmente comunicazione.
Per qualsiasi informazione si prega di contattare 
supp...@procne.it<mailto:supp...@procne.it> .
Rif. D.L. 196/2003

Find out more about ShapeBlue and our range of CloudStack related
services

IaaS Cloud Design &
Build<http://secure-web.cisco.com/1Yol7cn0c4CnDObcpSirV3DCPZ0WVdvOa3L
hGNjqR1LC8fdUx8eCLTnMMSoshd9HpKAnV6UPQ_yMd3M-1eZw2Ta-m7j5KgANh1cCgIkU
g7gUvZUUMIkYZDZDpYP9IDOTuw6o3kuFAtJGiF0j7g8WWr6r9HIr7CqwJi047V_38MGrr
r_r5JkLvVUoDdjYuhuBW/http%3A%2F%2Fshapeblue.com<http://2Fshapeblue.com>%2Fiaas-cloud-design-a
nd-build%2F%2F> CSForge - rapid IaaS 

Re: cpu overprovisioning

[Bharat Kumar]

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 3.
> 
> The UI not showing the over provisioned value seems like a bug.
> 
> -abhi
> 
> 
>> On 21-Apr-2015, at 6:34 pm, Ugo Vasi  wrote:
>> 
>> Hi all,
>> we have a cluster of three machines with 16 CPU at 2.2GHz each and we have 
>> set a cpu-overprovizioning to 3.
>> 
>> I would expect that the CPU system capacity of the dashboard appear with the 
>> sum of megahertz CPUs multiplied by three instead I get the real sum 
>> (108MHz).
>> 
>> I do not understand if this overprovisioning allows me to allocate more MHz 
>> of real ones asthe documentation say since in reality the virtual machines 
>> occupy on average only 20% of the computing power.
>> 
>> thanks in advance
>> 
>> --
>> 
>> U g o   V a s i
>> P r o c n e  s.r.l>)
>> via Cotonificio 45  33010 Tavagnacco IT
>> phone: +390432486523 fax: +390432486523
>> 
>> Le informazioni contenute in questo messaggio sono riservate e
>> confidenziali ed è vietata la diffusione in qualunque modo eseguita.
>> Qualora Lei non fosse la persona a cui il presente messaggio è
>> destinato, La invitiamo ad eliminarlo e a non leggerlo, dandocene
>> gentilmente comunicazione.
>> Per qualsiasi informazione si prega di contattare supp...@procne.it .
>> Rif. D.L. 196/2003
>> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & 
> Build
> CSForge – rapid IaaS deployment 
> framework
> CloudStack 
> Consulting
> CloudStack Software 
> Engineering
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
> 
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Incorrect Memory Usage in Dashboard When Overprovisoined

[Bharat Kumar]

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.factor” in a cluster, 
i.e. from 1 to 2, the used memory value in dashboard also changed (in this 
example, doubled) as well as total momory. After I shut down VMs in the cluster 
and start them, memory usage became correct.

  I found the code calculating the used momory but couldn’t understand the 
way to calculating and updating this value.

In com.cloud.capacity.CapacityManagerImpl.updateCapacityForHost(Host):
===
usedMemory += ((so.getRamSize() * 1024L * 
1024L)/ramOvercommitRatio)*clusterRamOvercommitRatio;
===

  In the code above, clusterRamOvercommitRatio updates instantly after 
overprovisioning factor sets, but ramOvercommitRatio only updates according to 
clusterRamOvercommitRatio when VM starts. This leads to inconsistency between 
the two variables.
  So my question is:

1.  Why calculating usedMemory in such way (devided by ramOvercommitRatio 
and then multiplied clusterRamOvercommitRatio)?

2.  Why NOT updating ramOvercommitRatio when overprovisioning factor 
changes, until when VM starts?

3.  How to fix incorrect memory usage without restarting VMs ?



Thanks.

Kelvin Cai,
Ping An Technology (Shenzhen) Co., Ltd. | Infrastructure.






The information in this email is confidential and may be legally privileged. If 
you have received this email in error or are not the intended recipient, please 
immediately notify the sender and delete this message from your computer. Any 
use, distribution, or copying of this email other than by the intended 
recipient is strictly prohibited. All messages sent to and from us may be 
monitored to ensure compliance with internal policies and to protect our 
business.
Emails are not secure and cannot be guaranteed to be error free as they can be 
intercepted, amended, lost or destroyed, or contain viruses. Anyone who 
communicates with us by email is taken to accept these risks.

收发邮件者请注意：
本邮件含保密信息，若误收本邮件，请务必通知发送人并直接删去，不得使用、传播或复制本邮件。
进出邮件均受到本公司合规监控。邮件可能发生被截留、被修改、丢失、被破坏或包含计算机病毒等不安全情况。

Re: Could use a little help

[Bharat Kumar]

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
> 
> 
> 
> On Aug 8, 2014, at 7:40 PM, Xerex Bueno  wrote:
> 
>> We have just installed ACS 4.4 on Vmware running Nexus 1000v.  It creates 
>> the zone but has issues starting the system Vms.  Can someone take a look at 
>> the log below and give me your best guess as to what is going wrong please.
>> 
>> java.lang.NumberFormatException: null
>> at java.lang.Integer.parseInt(Integer.java:454)
>> at java.lang.Integer.parseInt(Integer.java:527)
>> at 
>> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:484)
>> at 
>> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2351)
>> at 
>> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1607)
>> at 
>> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:449)
>> at 
>> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
>> at 
>> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>> at 
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>> at 
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>> at 
>> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>> at 
>> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>> at 
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
>> at 
>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
>> at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:745)
>> 2014-08-08 21:20:44,999 DEBUG [c.c.a.m.DirectAgentAttache] 
>> (DirectAgent-11:ctx-da7b943b) Seq 1-6699385920690323610: Cancelling because 
>> one of the answers is false and it is stop on error.
>> 2014-08-08 21:20:44,999 DEBUG [c.c.a.m.DirectAgentAttache] 
>> (DirectAgent-11:ctx-da7b943b) Seq 1-6699385920690323610: Response Received: 
>> 2014-08-08 21:20:45,000 DEBUG [c.c.a.t.Request] 
>> (DirectAgent-11:ctx-da7b943b) Seq 1-6699385920690323610: Processing:  { Ans: 
>> , MgmtId: 345052286326, via: 1, Ver: v1, Flags: 10, 
>> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":6,"name":"v-6-VM","bootloader":"HVM","type":"ConsoleProxy","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":1073741824,"maxRam":1073741824,"hostName":"v-6-VM","arch":"x86_64","os":"Debian
>>  GNU/Linux 5.0 (64-bit)","platformEmulator":"debian5Guest","bootArgs":" 
>> template=domP type=consoleproxy host=10.10.1.12 port=8250 name=v-6-VM zone=1 
>> pod=1 guid=Proxy.6 proxy_vm=6 disable_rp_filter=true eth2ip=96.38.39.84 
>> eth2mask=255.255.255.0 gateway=96.38.39.81 eth0ip=0.0.0.0 eth0mask=0.0.0.0 
>> eth1ip=10.100.1.171 eth1mask=255.255.255.0 mgmtcidr=10.10.1.0/24 
>> localgw=10.100.1.1 internaldns1=10.10.1.10 dns1=8.8.8.8 
>> dns2=4.2.2.2","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"df11bf739d02f384","params":{"nicAdapter":"E1000","vmware.reserve.cpu":"false","vmware.reserve.mem":"false"},"uuid":"42f0c842-ccdd-47bd-a6e3-9edb35ddd0ea","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"6b0fce07-bff8-4523-aec4-4fdcf2186f5e","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"62160fe2-b9e5-4357-b4ef-987626f26a56","id":1,"poolType":"LVM","host":"10.100.1.12","path":"datastore-16","port":0,"url":"LVM://10.100.1.12/datastore-16/?ROLE=Primary&STOREUUID=62160fe2-b9e5-4357-b4ef-987626f26a56"}},"name":"ROOT-6","size":0,"path":"ROOT-6-01","volumeId":6,"vmName":"v-6-VM","accountId":1,"format":"OVA","id":6,"deviceId":0,"hypervisorType":"VMware"}},"diskSeq":0,"path":"ROOT-6-01","type":"ROOT","_details":{"managed":"false","storagePort":"0","storageHost":"10.100.1.12","volumeSize":"0"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"a9c80c9c-bac3-4357-b0dd-34db97f4f0e4","ip":"96.38.39.84","netmask":"255.255.255.0","gateway":"96.38.39.81","mac":"06:79:04:00:00:65","dns1":"8.8.8.8","dns2":"4.2.2.2","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://999","isolationUri":"vlan://999","is

Re: Fail to configure network interface when booting VM

[Bharat Kumar]

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 all,
> 
> I am using CloudStack4.2 advanced zone in Ubuntu12.04. I use host
> A(10.10.101.103) as my management server, and use host B(10.10.101.107) as
> my agent host. I meet a problem that the VM booted in host B fail to
> configure network interface when boot up. In other words, when I type
> `ifconfig` in VM booted in host B, I find the IP address is missing!
> However, there is no problem with the VM booted in host A.
> 
> BTW, I both add a network bridge "cloudbr0" in management server(A) and
> agent host(B). Both server A and B can access the internet and I can access
> them from outside. So, I have no idea now. Can anyone tell me how to debug
> or provide me with some clue? Thanks!
> 
> --
> Best Regards,
> Frank

Re: router VM failed - reservedCpu: 0, requested cpu: 500,

[Bharat Kumar]

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":{"result":false,"details":"Stopped
 by previous 
failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
 by previous failure","wait":0}}] }

2013-12-20 15:30:59,455 WARN  
[network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-2:job-39 = [ 
069c2587-3000-45ae-979f-887dc1e99b23 ]) Unable to ssh to the VM: Can not ping 
System vm r-9-VMdue to:Unable to connect

This means that the management server is not able to ssh to the router vm. This 
can happen if there is  a mismatch in the ssh keys used my the management 
server and the routerVM.  try to destroy the router VMs can recreate them.
If this dose not work try  copying  the systemvm.iso to the KVM host and 
recreate router VM again.

Thanks,
Bharat.

On 21-Dec-2013, at 5:34 am, James Towner 
mailto:james.tow...@yahoo.com>> wrote:

{"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":{"result":false,"details":"Stopped
 by previous 
failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
 by previous failure","wait":0}}] }

Re: incorrect cpu usage values in dashboard

[Bharat Kumar]

Hi Valery,

if you change the  cpu.overprovisioning.factor  for a cluster it will not 
effect the running VMs, only the VMs deployed after 
overcommit change will be effected.  In other words cloudstack will not 
reconfigure the running VMs with the new overcommit values. 

Also cloudstack adjusts the the cpu and memory  in DB ,  of the running VMs 
based on the new overcommit values.
new overcommitted allocation value = Actual allocated * new overprovisioning 
factor.

On Oct 15, 2013, at 5:23 PM, Valery Ciareszka 
 wrote:

> Hi, Bharat
> 
> No, I see incorrect values AFTER the 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 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 
>> wrote:
>> 
>>> Hi all.
>>> 
>>> I'm using CS 4.2.0 / CentOS 6.4/KVM  and I faced the following problem:
>>> If cpu.overprovisioning.factor for cluster is being changed, dashboard
>>> reports incorrect values, unless all vms are restarted (stop/start).
>>> 
>>> I.e. I configured cluster and set cpu.overprovisioning.factor to 6 and
>>> started a number of VMS:
>>> 
>>> http://thesuki.org/temp/ss/2013-10-15_10-59-43.png
>>> http://thesuki.org/temp/ss/2013-10-15_11-00-05.png
>>> http://thesuki.org/temp/ss/2013-10-15_11-00-40.png
>>> Current usage is reported correctly.
>>> 
>>> Further steps to reproduce bug:
>>> change cpu.overprovisioning.factor to 12 at cluster settings:
>>> http://thesuki.org/temp/ss/2013-10-15_11-01-06.png
>>> 
>>> You will see that cpu current usage hasn't changed.
>>> http://thesuki.org/temp/ss/2013-10-15_11-01-25.png
>>> 
>>> Wait for 5-10 minutes and you will see that cpu usage was doubled(in this
>>> test case some VMs were shut down, so the values ​​do not differ at
>> exactly
>>> 2х. :
>>> http://thesuki.org/temp/ss/2013-10-15_11-06-03.png
>>> 
>>> If vm is stopped and started, then it's consumed CPU is reported
>> correctly.
>>> If you will stop/start all vms (including system vms/virtual routers),
>> then
>>> you will see true CPU usage in dashboard.
>>> 
>>> I've submitted a bug at
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4868
>>> 
>>> --
>>> Regards,
>>> Valery
>>> 
>>> http://protocol.by/slayer
>> 
>> 
> 
> 
> -- 
> Regards,
> Valery
> 
> http://protocol.by/slayer

Re: incorrect cpu usage values in dashboard

[Bharat Kumar]

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 
 wrote:

> Hi all.
> 
> I'm using CS 4.2.0 / CentOS 6.4/KVM  and I faced the following problem:
> If cpu.overprovisioning.factor for cluster is being changed, dashboard
> reports incorrect values, unless all vms are restarted (stop/start).
> 
> I.e. I configured cluster and set cpu.overprovisioning.factor to 6 and
> started a number of VMS:
> 
> http://thesuki.org/temp/ss/2013-10-15_10-59-43.png
> http://thesuki.org/temp/ss/2013-10-15_11-00-05.png
> http://thesuki.org/temp/ss/2013-10-15_11-00-40.png
> Current usage is reported correctly.
> 
> Further steps to reproduce bug:
> change cpu.overprovisioning.factor to 12 at cluster settings:
> http://thesuki.org/temp/ss/2013-10-15_11-01-06.png
> 
> You will see that cpu current usage hasn't changed.
> http://thesuki.org/temp/ss/2013-10-15_11-01-25.png
> 
> Wait for 5-10 minutes and you will see that cpu usage was doubled(in this
> test case some VMs were shut down, so the values ​​do not differ at exactly
> 2х. :
> http://thesuki.org/temp/ss/2013-10-15_11-06-03.png
> 
> If vm is stopped and started, then it's consumed CPU is reported correctly.
> If you will stop/start all vms (including system vms/virtual routers), then
> you will see true CPU usage in dashboard.
> 
> I've submitted a bug at
> https://issues.apache.org/jira/browse/CLOUDSTACK-4868
> 
> -- 
> Regards,
> Valery
> 
> http://protocol.by/slayer

Re: [PROPOSAL] Dynamic Compute Offering

[Bharat Kumar]

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 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 creation without the need to 
> choose the fixed amount of compute mentioned in the pre created service 
> offerings. 
> Also allow users to specify the size of the root disk while using templates. 
> 
> users can specify their own compute requirements at the time of VM creation, 
> if they do not want to use fixed values in the pre created service offerings. 
> This is similar to the custom disk offering.
> 
> This will Allow
> 1.)  Admins to create service offerings by marking cpu, memory and root disk 
> as  dynamic parameters. 
> 2.)  users to use this dynamic service offering to specify the  memory, cpu 
> and root disk at the time of VM creation or upgrade.
> 3.)  Metering of these dynamically assigned resources for usage details. 
> 
> I have created a feature bug  for this.
> https://issues.apache.org/jira/browse/CLOUDSTACK-4738
> 
> Regards,
> Bharat. 
> 
> 
> 
> 
> 
> 

[PROPOSAL] Dynamic Compute Offering

[Bharat Kumar]

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 creation without the need to 
choose the fixed amount of compute mentioned in the pre created service 
offerings. 
Also allow users to specify the size of the root disk while using templates. 

users can specify their own compute requirements at the time of VM creation, if 
they do not want to use fixed values in the pre created service offerings. This 
is similar to the custom disk offering.

This will Allow
1.)  Admins to create service offerings by marking cpu, memory and root disk as 
 dynamic parameters. 
2.)  users to use this dynamic service offering to specify the  memory, cpu and 
root disk at the time of VM creation or upgrade.
3.)  Metering of these dynamically assigned resources for usage details. 

I have created a feature bug  for this.
https://issues.apache.org/jira/browse/CLOUDSTACK-4738

Regards,
Bharat. 

Re: KVM/mem.overprovisioning.factor

[Bharat Kumar]

Hi Dinu,
you can change the system service offering in 4.2.

refer to this link 
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.1/html/Admin_Guide/system-service-offerings.html

This is for 4.1 but will work with 4.2 as well.

As per the overcommit settings getting applied to the routervm,  it might be 
useful if you want to optimize the resource usage based on the usage pattern. 
say if do not know the amount of memory required during peak usage, but you 
know the minimum memory required. you can use this info to launch a router vm 
which uses the minimum memory most of 
the time under normal usage but can also scale its memory when required during 
the peak usage without the need to stop the router VM. 

Regards,
Bharat.

On Aug 22, 2013, at 8:45 PM, Dinu Arateanu  wrote:

> Thanks Bharat,
> 
> As far as I'm aware, the only way to change the default system VM offering 
> for a domain router can be done by modifying the database (altering the 
> disk_offerings table). One can change it when a router is not running, but 
> with multiple routers in a cloud it may become tedious. 
> 
> Concerning the secondary storage, there is a global setting, but last time I 
> checked it's undocumented (one needs to fill in the service offering database 
> ID, which isn't visible through Cloud UI). 
> 
> I'd rather see a more straightforward approach. Ideally, system VMs should 
> not be affected by overprovisioning 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, Dinu Arateanu 
>> wrote:
>> 
>>> Hello,
>>> 
>>> I'm testing ACS 4.2 with kvm. I noticed that when one configures 
>>> mem.overprovisioning.factor Global/Cluster setting, chances are that the 
>>> System VMs configured with an offer of 128 MB RAM will never start (namely 
>>> the Domain Router and the SSVM). 
>>> 
>>> According to the agent.log, ACS sends libvirt the request to start the VM 
>>> with a "currentMemory" parameter equal to the System Offering RAM divided 
>>> by mem.overprovisioning.factor:
>>> 
>>> 2013-08-21 11:02:34,824 DEBUG [cloud.agent.Agent] 
>>> (agentRequest-Handler-1:null) Request:Seq 1-1537935677:  { Cmd , MgmtId: 
>>> 117981950658, via: 1, Ver: v1, Flags: 100011, 
>>> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":13,"name":"
>>> r-13-VM","type":"DomainRouter","cpus":1,"minSpeed":125,"maxSpeed":500,"minRam":33554432,"maxRam":134217728,"arch":"x86_64","os":"Debian
>>>  GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP name=r-13-VM 
>>> eth0ip=10.10.40.10 eth0mask=
>>> 255.255.255.0 gateway=10.10.40.1 domain=dev.int dhcprange=10.10.40.1 
>>> eth1ip=169.254.3.215 eth1mask=255.255.0.0 type=dhcpsrvr 
>>> disable_rp_filter=true 
>>> dns1=8.8.8.8","rebootOnCrash":false,"enableHA":true,"limitCpuUse":false
>>> ,"enableDynamicallyScaleVm":false,"vncPassword":"*","params":{"memoryOvercommitRatio":"4","cpuOvercommitRatio":"4"},"uuid":"52caa75a-5331-4979-9456-18d1b743b7ad","disks":[{"data":{"org.apache.cloudstack.storage.to.
>>> VolumeObjectTO":{"uuid":"c84b6834-6bab-4087-a044-e61a1e3a391b","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c1ac7425-f6d2-3ada-b78a-b17faceb89ea","id":2,"poolType":"RBD","host":"
>>> ceph.dev.int","path":"rbd1","port":6789}},"name":"ROOT-13","size":272915248,"path":"329df94f-4c30-4617-9fbd-440b76f08cde","volumeId":13,"vmName":"r-13-VM","accountId":1,"format":"RAW","id":13,"hypervisorType":"KVM"}},"di
>&g

Re: KVM/mem.overprovisioning.factor

[Bharat Kumar]

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, Dinu Arateanu 
 wrote:

> Hello,
> 
> I'm testing ACS 4.2 with kvm. I noticed that when one configures 
> mem.overprovisioning.factor Global/Cluster setting, chances are that the 
> System VMs configured with an offer of 128 MB RAM will never start (namely 
> the Domain Router and the SSVM). 
> 
> According to the agent.log, ACS sends libvirt the request to start the VM 
> with a "currentMemory" parameter equal to the System Offering RAM divided by 
> mem.overprovisioning.factor:
> 
> 2013-08-21 11:02:34,824 DEBUG [cloud.agent.Agent] 
> (agentRequest-Handler-1:null) Request:Seq 1-1537935677:  { Cmd , MgmtId: 
> 117981950658, via: 1, Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":13,"name":"
> r-13-VM","type":"DomainRouter","cpus":1,"minSpeed":125,"maxSpeed":500,"minRam":33554432,"maxRam":134217728,"arch":"x86_64","os":"Debian
>  GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP name=r-13-VM 
> eth0ip=10.10.40.10 eth0mask=
> 255.255.255.0 gateway=10.10.40.1 domain=dev.int dhcprange=10.10.40.1 
> eth1ip=169.254.3.215 eth1mask=255.255.0.0 type=dhcpsrvr 
> disable_rp_filter=true 
> dns1=8.8.8.8","rebootOnCrash":false,"enableHA":true,"limitCpuUse":false
> ,"enableDynamicallyScaleVm":false,"vncPassword":"*","params":{"memoryOvercommitRatio":"4","cpuOvercommitRatio":"4"},"uuid":"52caa75a-5331-4979-9456-18d1b743b7ad","disks":[{"data":{"org.apache.cloudstack.storage.to.
> VolumeObjectTO":{"uuid":"c84b6834-6bab-4087-a044-e61a1e3a391b","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c1ac7425-f6d2-3ada-b78a-b17faceb89ea","id":2,"poolType":"RBD","host":"
> ceph.dev.int","path":"rbd1","port":6789}},"name":"ROOT-13","size":272915248,"path":"329df94f-4c30-4617-9fbd-440b76f08cde","volumeId":13,"vmName":"r-13-VM","accountId":1,"format":"RAW","id":13,"hypervisorType":"KVM"}},"di
> skSeq":0,"type":"ROOT"}],"nics":[{"deviceId":0,"networkRateMbps":1000,"defaultNic":true,"uuid":"c68fdd00-68e0-4755-b6e1-c07c4d122040","ip":"10.10.40.10","netmask":"255.255.255.0","gateway":"10.10.40.1","mac":"06:f2:0e:00:01:74"
> ,"dns1":"8.8.8.8","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://40","isolationUri":"vlan://40","isSecurityGroupEnabled":false,"name":"vswitch0"},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"1778dbb
> d-7d27-481a-96ad-99c9aac36e8f","ip":"169.254.3.215","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:03:d7","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"hostIp":"10.10.8.25","
> executeInSequence":false,"wait":0}},{"com.cloud.agent.api.check.CheckSshCommand":{"ip":"169.254.3.215","port":3922,"interval":6,"retries":100,"name":"r-13-VM","wait":0}},{"com.cloud.agent.api.GetDomRVersionCmd":{"accessDetails":{
> "router.name":"r-13-VM","router.ip":"169.254.3.215"},"wait":0}},{}] }
> [...]
> r-13-VM
> 52caa75a-5331-4979-9456-18d1b743b7ad
> Debian GNU/Linux 5.0 (32-bit)
> [...]
> 131072
> 32768
> 
> 
> 
> 1
> 
> hvm
> 
> 
> 
> 
> 125
> 
> restart
> destroy
> destroy
> 
> 
> As a result, the System VM will be created, but will never run - 32 MB RAM is 
> too low. I'm not arguing about how recommended it is to set a factor of 4 for 
> memory ballooning (outside testing environments), but rather that ACS should 
> start (at least the System) VMs with a minimum RAM. The virtio_balloon module 
> seems to be loaded within the SVM template, but it does not work. 
> 
> Is there any way to control how much minimum RAM ACS allocates based on the 
> service offering and the overprovisioning factor? 
> 
> Thanks,
> Dinu
> 
> 
> 

Re: CPU over-commitment

[Bharat Kumar]

Hi jerry,

In general overcommit is done when you know the usage pattern and have done 
some real time testing.  

The method suggested by you is also good but not scaleable :).  Generally in 
case of contention the host adjusts the cpu allocated to a vm based on the 
wight or some reservation. 

So in this scenario  as we know the usage pattern we should have deployed
them in different host or we can set some reservation based on the importance 
of the vm. 
 
Regards,
Bharat.
 
On Aug 16, 2013, at 11:13 AM, Jerry Jiang 
 wrote:

> Thanks. Kumar, what you commented is defiantly what I want.
> 
> 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 
> 
> -邮件原件-
> 发件人: Bharat Kumar [mailto:bharat.ku...@citrix.com] 
> 发送时间: 2013年8月16日 星期五 12:58
> 收件人: 
> 抄送: Jerry Jiang
> 主题: Re: CPU over-commitment
> 
> 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 done
> differently in different hypervisors. 
> 
> 
> So in the scenario below both the apps cannot be happy if VM1 and VM2 want
> to use 350% and 360% at the same time.
> 
> Overcommit is useful to increase the overall resource utilization. 
> 
> Overcommit is useful if the scenario was say VM1 uses 300% and VM2 uses 100%
> during 10-11 am and 
> form 11-12am  VM2 uses 300% where as VM1 uses 100%.   we have overcommitted
> the resource by allocation more than what we have, 
> this will keep the cpu utilization of the host near 100% most of the time
> and we will be able to launch more VMs as not all the VMs try to use the
> resource allocated to them at the same time.
> 
> Regards,
> Bharat.
> 
> On Aug 16, 2013, at 9:28 AM, Jerry Jiang 
> wrote:
> 
>> HI all,
>> 
>> 
>> 
>> I have question not figured out very well. (may not for CS, but I 
>> noticed CS supports CPU over-commitment)
>> 
>> 
>> 
>> Imaging the following case,
>> 
>> 
>> 
>> A host owns 4 physical CPUs
>> 
>> Because apps on VM1 consume 350% CPU during 10am-11am, so I gave VM1 4 
>> vCPUs to ensure performance
>> 
>> Because apps on VM2 consume 360% CPU during 10am-11am, so I gave VM2 4 
>> vCPUs to ensure performance
>> 
>> 
>> 
>> So I would ask if Apps are both happy with vm1 and vm2 during 
>> 10am-11am
>> 
>> 
>> 
>> If not, Is CPU over-commitment meaningful? How is your guys consider 
>> the over-commitment
>> 
>> 
>> 
>> Thanks
>> 
>> Jerry
>> 
>> 
>> 
> 

Re: CPU over-commitment

[Bharat Kumar]

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 done differently in different hypervisors. 


So in the scenario below both the apps cannot be happy if VM1 and VM2 want to 
use 350% and 360% at the same time.

Overcommit is useful to increase the overall resource utilization. 

Overcommit is useful if the scenario was say VM1 uses 300% and VM2 uses 100% 
during 10-11 am and 
form 11-12am  VM2 uses 300% where as VM1 uses 100%.   we have overcommitted the 
resource by allocation more than what we have, 
this will keep the cpu utilization of the host near 100% most of the time and 
we will be able to launch more VMs as not all the VMs try to use the 
resource allocated to them at the same time.

Regards,
Bharat.

On Aug 16, 2013, at 9:28 AM, Jerry Jiang 
 wrote:

> HI all,
> 
> 
> 
> I have question not figured out very well. (may not for CS, but I noticed CS
> supports CPU over-commitment)
> 
> 
> 
> Imaging the following case,
> 
> 
> 
> A host owns 4 physical CPUs
> 
> Because apps on VM1 consume 350% CPU during 10am-11am, so I gave VM1 4 vCPUs
> to ensure performance
> 
> Because apps on VM2 consume 360% CPU during 10am-11am, so I gave VM2 4 vCPUs
> to ensure performance
> 
> 
> 
> So I would ask if Apps are both happy with vm1 and vm2 during 10am-11am
> 
> 
> 
> If not, Is CPU over-commitment meaningful? How is your guys consider the
> over-commitment
> 
> 
> 
> Thanks
> 
> Jerry
> 
> 
>