You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "Prachi Damle (JIRA)" <ji...@apache.org> on 2013/04/22 20:03:16 UTC
[jira] [Assigned] (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.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Prachi Damle reassigned CLOUDSTACK-2102:
----------------------------------------
Assignee: Prachi Damle
> 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