Reviewed-by: Sheng Yang
Changes:
- Do not check if allocation_state is 'Enabled' in planner if the caller is Root Admin.
- This should let Root Admin create a VM in a disabled Zone.
Reviewed-By: Alex
Changes:
- Reuse the same storagepool where the Volume is ready on each retry of VM deployment until the cluster where the volume is has capacity
- After the cluster is out of capacity, we look in other clusters and find a new storagepool.
- At this point if the volume is recreatable on the new storagepool, depoyment will succeed provided everytyhing else goes through
- But if the volume is not recreatable and its cluster is out of capacity, we will still fail to deploy the VM
fullHostSync() is messed up.
The sync operation have been done twice, and for the second time, the original
info has already cleared, so default value "Stopped" is created, then result in
stop all the vms.
The fullHostSync() is skipped for Xen, so Xen don't have this issue.
status 12586: resolved fixed
Changes:
- VirtualMachineMgr puts the constraint that if Root volume is already READY, we provide the clusterId in the plan to the deploymentPlanner. Planner then searches for resources only under that cluster.
- If no deployment could be found, deploying VM fails.
- Fixed this, such that incase the root volume is recreatable, we call the planner again by removing the cluster constraint. Planner will then search for resources in other clusters.
- Works for system VMs(SSVM, consoleproxy, virual routers).
1) Introduce new managers - ProjectManager and DomainManager. Moved all domain related code from AccountManager to DomainManager.
2) Moved some code from ManagementServerImpl to the correct managers.
3) New resource limit for Domain - Project
Reviewed-by: Alex
Changes:
- When management server starts, it goes through all the pending work items from op_it_work table and schedules HA work for each. It used to mark each item as done. Instead we should keep the item as pending and let it get marked as Done after the HA work is done.
- Changes in VirtualMachineMgr::advanceStop() :
a) if we find a VM with null hostId, we stop the VM only if it is forced stopped.
b) if VM state transition to Stopping fails,for state Starting and Migrating we try to find the pending work item and then do cleanup the VM. In case state is Stopping we can cleanup directly.
c) We proceed releasing all resources only if state transitioned to 'Stopping'.
- Changes in HA:
a) Depend on VirtualMachineMgr::advanceStop() in case host is not found to do VM cleanup
- When Vm state between mgmt server and agent syncs from starting -> running, mark any pending work item as done.
Conflicts:
server/src/com/cloud/vm/VirtualMachineManagerImpl.java
reviewed-by: Alex/Kelven
Changes:
1. UserVmManagerImpl :: finalizeStart()
Added null check for the cmds.getAnswers() object. Return ‘true’ if null.
2. VirtualMachineManagerImpl :: advanceStart()
Move the line to set PodId to the vm being started above the state transition where hostId gets set, so that podId is not null in case management server goes down when vm starts on the agent. On restart, podId is not updated during fullsync. So this will prevent podId remaining null.
vm.setPodId(dest.getPod().getId());
Changes:
To make sure migration does not attempt to pick a host that has running VMs more than the max guest VM's limit:
- Changed manual migration to call host allocators to return a list of hosts suitable for migration. Host allocators check for the max guest VM limit.
- Earlier we returned hosts with enough capacity but now Host Allocators make other checks along with capacity. So the list of hosts returned are hosts that have enough capacity AND satisfy all other conditions like host tags, max guests limit etc. Or in other words Allocators dont return the hosts that dont satisfy all conditions even if they have capacity.
-Therefore, now we mark the list of hosts returned for manual migration as 'suitable' hosts instead of 'hasenoughCapacity' in the HostResponse.
- HA migration already calls allocators, so no change is needed there.