[ https://issues.apache.org/jira/browse/CLOUDSTACK-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Prachi Damle resolved CLOUDSTACK-2102. -------------------------------------- Resolution: Fixed > 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