You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Harikrishna Patnala (JIRA)" <ji...@apache.org> on 2013/07/28 08:19:48 UTC
[jira] [Resolved] (CLOUDSTACK-3809) there is calculation mismatch
for Total,used , available capacity in CS for xen cluster and on xen host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Harikrishna Patnala resolved CLOUDSTACK-3809.
---------------------------------------------
Resolution: Later
Hi,
We do have the same kind of overhead calculation in VMWare also.
we dont account overhead, but these things need to be improved by quering host for overhead values.
But this wont fail deploying or scaling VM since it retries on another host.
Admin should aware of this overhead in order to use the service dynamic scaling of VM.
> there is calculation mismatch for Total,used , available capacity in CS for xen cluster and on xen host
> ----------------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-3809
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3809
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the default.)
> Affects Versions: 4.2.0
> Environment: branch 4.2;hypervisor =xen
> Reporter: prashant kumar mishra
> Assignee: Harikrishna Patnala
> Priority: Critical
> Fix For: 4.2.0
>
> Attachments: Logs_XS_DB.rar, screenshot-1.jpg, screenshot-2.jpg, VMs_with_scaleup_flag_False.jpg
>
>
> Memory calculation on xen host and CS
> ================================
> AVL MEM=available memory
> ON CS (in MB) || ON XEN HOST(in MB)
>
> TOTAL 15440.137 || 16374
> USED 14208 || 15924
>
> AVL MEM 1232.137 || 451
> Total MEM difference =1232.137 - 451 = 781.137
> Due to this mismatch allocator chose the host but vm deployment fails at run time
> 1-2013-07-25 14:21:32,101 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-12:job-24 = [ 6f32f9f4-5185-411f-b75e-3c05cbb475f4 ]) Deployment found - P0=VM[User|test12], P0=Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage(Volume(29|ROOT-->Pool(1))]
> 2- errorInfo: [HOST_NOT_ENOUGH_FREE_MEMORY, 588251136, 469716992]
> Steps to reproduce
> -----------------------------
> 1-preapre a CS setup with a xen 6.1 host(advance license)
> 2-create a service offering say ram (cpu=500,RAM=3.00 GB)
> 4- set cluster.(cpu/memory).allocated.capacity.disablethreshold to one
> 5-set enable.dynamic.scale.vm to true
> 6-deploy some vms using SO ram , SO small instance ( in my setup i was able to deploy 4 vm with SO ram +1vms with SO small instance)
> 7-if vms are scalable then on host AVL MEM= 425 MB and if vms are not scalable then AVL MEM = 523 (please check screenshot for more details)
> Expected
> ----------------
> Deployment should be successful
> Actual
> --------------
> deployment failed with run time error
> My observation
> -------------------------
> 1->Memory overhead for vm deployed with 3 GB ram is 129 MB and for vm with 512 MB ram is 49 MB
> 2-> four VM 129*4=516 + For two small vm 49*1=49 +system vm overhead 41(cpvm) +35(ssvm) +34 (rvm)
> 3->Total overhead= 516+98+41+35+34=675 MB which is nearly equal to total MEM difference
> 4-->we should also consider memory overhead and should add it in used capacity to minimize this gap
> DB:
> ====
> mysql> select * from op_host_capacity where capacity_type=0\G;
> *************************** 1. row ***************************
> id: 1
> host_id: 1
> data_center_id: 1
> pod_id: 1
> cluster_id: 1
> used_capacity: 14898167808
> reserved_capacity: 0
> total_capacity: 16190157312
> capacity_type: 0
> capacity_state: Enabled
> update_time: 2013-07-25 18:21:47
> created: 2013-07-25 15:40:51
> 1 row in set (0.00 sec)
> ERROR:
> No query specified
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira