cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chandan Purushothama (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (CLOUDSTACK-2102) Anti-Affinity - Even after reserved capacity has been released for a Vm in "Stopped" state , we are not allowed to deploy new Vms as part of same anti-affinity group in the last_host_id where the stopped Vm was running.
Date Fri, 09 Aug 2013 00:11:47 GMT

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

Chandan Purushothama closed CLOUDSTACK-2102.
--------------------------------------------


Verified on 4.2 Build.
                
> Anti-Affinity - Even after reserved capacity has been released for a Vm in "Stopped"
state , we are not allowed to deploy new Vms as part of same anti-affinity group in the last_host_id
where the stopped Vm was running. 
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-2102
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2102
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.2.0
>         Environment: Latest build from master
>            Reporter: Sangeetha Hariharan
>            Assignee: Prachi Damle
>             Fix For: 4.2.0
>
>
> Anti-Affinity - Even after reserved capacity has been release for a Vm in "Stopped" state
, we are not allowed to deploy new Vms as part of same anti-affinity group in the last_host_id
where the stopped Vm was running.
> Steps to reproduce the problem:
> PreReq:
> 1. Have 2 hosts in the set up.
> 2. Create new anti-affinity groups.
> 3. Deploy 2 Vms in tha same anti-affinity group.
> Steps:
> 1. Stop one of Vms.
> 2. Deploy a new VM in the same anti-affinity group  after the capacity.skipcounting.hours
interval has expired.
> Expected Behavior:
> Vm deployment should succeed and will be assigned the host that had the stoped Vm running
previously.
> Actual Result:
> We see the Vm deployment fail ,because the last_host_id for the stopped Vm does not get
cleared even after the capacity.skipcounting.hours interval has passed and the reserved capacity
has been released for this Vm.
> Management server logs:
> 2013-04-18 17:24:56,088 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
Found 2 VMs on host 8
> 2013-04-18 17:24:56,089 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
Found 0 VM, not running on host 8
> 2013-04-18 17:24:56,092 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
No need to calibrate cpu capacity, host:8 usedCpu: 102
> 4 reservedCpu: 0
> 2013-04-18 17:24:56,092 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
No need to calibrate memory capacity, host:8 usedMem:
> 1048576000 reservedMem: 0
> 2013-04-18 17:24:56,096 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
Found 0 VMs on host 9
> 2013-04-18 17:24:56,098 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
Found 1 VM, not running on host 9
> 2013-04-18 17:24:56,101 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
Calibrate reserved cpu for host: 9 old reservedCpu:512
>  new reservedCpu:0
> 2013-04-18 17:24:56,101 DEBUG [cloud.capacity.CapacityManagerImpl] (CapacityChecker:null)
Calibrate reserved memory for host: 9 old reservedMem:
> 524288000 new reservedMem:0
> 2013-04-18 17:24:56,109 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Done
executing cpu/ram capacity update
> 2013-04-18 17:24:56,109 DEBUG [cloud.alert.AlertManagerImpl] (CapacityChecker:null) Executing
storage capacity update
> mysql> select uuid,state,id ,host_id,last_host_id from vm_instance where id=34;
> +--------------------------------------+---------+----+---------+--------------+
> | uuid                                 | state   | id | host_id | last_host_id |
> +--------------------------------------+---------+----+---------+--------------+
> | 13368555-4677-4a4d-8b9b-c63cb3465202 | Stopped | 34 |    NULL |            9 |
> +--------------------------------------+---------+----+---------+--------------+
> 1 row in set (0.00 sec)

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