Changes:
- We were ordering clusters based on capacity of the first-fit host found in each cluster. Due to this, there were cases where we deployed VMs to one cluster instead of balancing off within clusters.
- Now we order the list of clusters by aggregate capacity and choose the ones that have enough capacity for the required VM in this order.
- This should balance the load between clusters instead of bombarding one.
Conflicts:
server/src/com/cloud/capacity/dao/CapacityDao.java
server/src/com/cloud/capacity/dao/CapacityDaoImpl.java
e.g: command=configuresimulator&name=SecurityIngressRulesCmd&zoneid=1&value=enabled:true|timeout=30, means enable command SecurityIngressRulesCmd for zone 1, and wait for 30 seconds.
Changes:
- Added a new API 'migrateSystemVm' backed by MigrateSystemVMCmd.java to migrate system VMs (SSVM, consoleproxy, domain routers(router, LB, DHCP))
- This is Admin only action
- The existing API 'migratevirtualmachine' is only for user VMs
Otherwise they can't be deserialized.
Fix the following exception on KVM host:
ERROR [agent.transport.Request] (Agent-Handler-2:null)
Caught problem with
[{"ClusterSyncCommand":{"_interval":60,"_skipSteps":20,"_steps":0,"_clusterId":2,"contextMap":{},"wait":0}}]
com.google.gson.JsonParseException: The JsonDeserializer
com.cloud.agent.transport.ArrayTypeAdaptor@44ed904 failed to deserialized json
object
[{"ClusterSyncCommand":{"_interval":60,"_skipSteps":20,"_steps":0,"_clusterId":2,"contextMap":{},"wait":0}}]
given the type class [Lcom.cloud.agent.api.Command;
...
Caused by: java.lang.RuntimeException: No-args constructor for class
com.cloud.agent.api.ClusterSyncCommand does not exist. Register an
InstanceCreator with Gson for this type to fix this problem.
at
com.google.gson.MappedObjectConstructor.constructWithNoArgConstructor(MappedObjectConstructor.java:64)
...
This bug also happens in XenServer 5.6 FP1, but this issue is hidden by bug 11564.
There are two issues here
1. in XenServer 5.6 FP1/SP2, when a slave host is down ( NIC is unplugged), and before master detect the slave is down( it takes about 10 minutes),
template.createClone doesn't work sometime, it complains can not contact slave host, looks like XenServer try to start VM on this slave host, we use VM.create instead, we can specify host in VM.create API, so it will not try to connect the slave
2. in XenServer 5.6 FP1/SP2, host tag is introduced into VDI, however in HA case, VM.reset_powerstate and VM.destory doesn't remove this host tag, when CloudStack try to start this VM on other host, XenServer complains this VDI is already used ( or mount as RW). CloudStack will manually remove the host tage in VDI in FenceCommand
status 11552: resolved fixed
Edison Su
prachi
Edison Su
Nitin
Sheng Yang
Jessica Wang
anthony
alena
Murali Reddy
Jessica Tomechak
kishan
Alex Huang
Abhinandan Prateek
Kelven Yang
frank