cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harikrishna Patnala (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CLOUDSTACK-3809) there is calculation mismatch for Total,used , available capacity in CS for xen cluster and on xen host
Date Sun, 28 Jul 2013 06:19:48 GMT

     [ 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

Mime
View raw message