cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangeetha Hariharan (JIRA)" <j...@apache.org>
Subject [jira] [Created] (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, 19 Apr 2013 00:43:15 GMT
Sangeetha Hariharan created CLOUDSTACK-2102:
-----------------------------------------------

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