If the scaling up fails on the host the vm is running on try to migrate it to other hosts in the cluster and try scaling.
CLOUDSTACK-3349
For deciding the host in the cluster try the new deployment manager now
Signed off by : nitin mehta<nitin.mehta@citrix.com>
Description: Adds API calls updateDefaultNicForVirtualMachine,
addNicToVirtualMachine, and removeNicFromVirtualMachine. These are
intended to allow a user to modify a VM's configuration post
deployment, to adjust the networks to which the VM belongs.
BUG-ID: CLOUDSTACK-645
Submitted-by: Brian Angus <blangus@betterservers.com>
Submitted-by: Ryan Dietrich <ryan@betterservers.com>
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1359494800 -0700
Fixed the bug where vm_instance.ha_enabled wasn't updated during service offering upgrade
Conflicts:
server/src/com/cloud/server/ManagementServerImpl.java
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
Changes:
- Added a new parameter to pass in deployment plan during vm start
- If a hostId is passed in to the DeployVMCmd (only allowed for a root admin to test a host), a plan is passed in to start the vm in that host's datacenter, pod and cluster and on that host
- If a plan is passed in during start, but if the VM's root volume is READY, then plan of the root volume takes precedence. In that case the plan passed in is not used.
Changes:
- When migration fails we try to do cleanup on the destination host agent. The AgentUnavailableException in this cleanup was not caught.
-Due to that other cleanup like reverting capacity allocated and vm state were skipped.
-Fix is to catch the AgentUnavailableException so that rest of the cleanup can happen.
- Also corrected the exceptions in various cases of migration failure.
- In case the VM is still starting, HA should schedule a retry. Introduced a special migration exception for handling this.
This is a Root admin only functionality
---------------------
Service API changes:
---------------------
- ManagementServer will expose new API:
Pair<List<HostVO>, List<Long>> listHostsForMigrationOfVM(UserVm vm, Long
startIndex, Long pageSize)
The API returns list of all hosts in the VM's cluster minus the current host and also a list of hostIds that seem to have enough CPU and RAM capacity to host this VM.
- ListHostsCmd will call this service API if virtualmachineid is present in the request.
- MigrateVmCmd is the new command added that takes in virtualmachineid and destination hostid
- UserVmService will expose a new API: UserVm migrateVirtualMachine(UserVm vm, Host destinationHost)
------------------------------------
API throws error in following cases:
------------------------------------
- User is not a root Admin. (‘Permission denied’)
- A VM uses local storage, we cannot migrate it, so ‘listHosts’ will throw error.
- We fail to migrate the VM on the chosen host.
- API will support migration for XenServer only currently. So error is thrown
if hypervisor is not XenServer (e.g KVM, vSphere etc)
- Destination host is not in same cluster as source host.
- VM is not in running state
status 7811: resolved fixed
Other fixes:
* vmExpunge: cleanup LB/PF rules after vm was marked as Expunging in the DB to avoid the situation when user recovers a vm in the middle of expunge job.
