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:50 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-3809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Harikrishna Patnala resolved CLOUDSTACK-3809.
---------------------------------------------

    Resolution: Not A Problem
    
> 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