We are using v1 now, instead of v3. This bug result in all the commands from
the other clustered management server would be sent to agentmanager, and then dropped.
status 10135: resolved fixed
Changes:
- When a host connects, we check if it has a CPU and RAM entry in capacity table. If the entry is found, the values are updated if possible. If the entry is not found a new one is inserted.
- The searchCriteria used to check if CPU entry is present was wrong. We were passing in a criteria which did not specify capacityType. So for hostId >= 200, the serach would return capacity entries of storage pools also since poolIDs start from 200 onwards.
- Since an entry was found (although the wrong one), we tried to update it. But update does not happen since the capacity ranges dont match.
And a new insert for CPU also does not happen since an entry is found.
- So as a result CPU entries are never inserted in the table for hostIds >=200
- As a fix, corrected the search criteria.
- During VM deployment, when the entry is not found, we get a NPE. Added a null check to avoid that.
status 9623: resolved fixed
Also set ram_size to 1024 for console proxy offering during the upgrade
Conflicts:
core/src/com/cloud/vm/SecondaryStorageVmVO.java
server/src/com/cloud/agent/manager/allocator/impl/UserConcentratedAllocator.java
server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java
server/src/com/cloud/storage/allocator/LocalStoragePoolAllocator.java
server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java
Changes:
- Changed host allocators/planner to use cpu.overprovisioning.factor
- Removed following: while adding a new host, we were setting the total_cpu in op_host_capacity to be actual_cpu * cpu.overprovisioning.factor. Now we set it to actual_cpu.
- ListCapacities response now calculates the total CPU as actual * cpu.overprovisioning.factor (This change does not add anything new - listCapacities was pulling total CPU from op_host_capacity DB earlier which had the cpu.overprovisioning.factor applied already. Now we need to apply it over the DB entry.)
- HostResponse has a new field: 'cpuWithOverprovisioning' that returns the cpu after applying the cpu.overprovisioning.factor
- Db Upgrade 222 to 224 now updates the total_cpu in op_host_capacity to be the actual_cpu for each Routing host.
status 7704: resolved fixed
For user vm:
* for default network, take limit from the corresponding service offering
* for all additional networks, take limit from the network offerings
For domainRouter/SSVM/CPVM:
* get info from the network offering
Added new config parameter: "vm.network.throttling.rate". If nw_rate is NULL for serviceOffering, this parameter would be used for default vm's network
- Added a new flag 'allocation_state' to zone,pod,cluster and host
- The possible values for this flag are 'Enabled' or 'Disabled'
- When a new zone,pod,cluster or host is added, allocation_state is 'Disabled' by default.
- For existing zone,pod,cluster or host, the state is 'Enabled'.
- All Add/Update/List commands for each of zone,pod,cluster or host can now take a new parameter 'allocationstate'
- If 'allocation_state' is 'Disabled', Allocators skip that zone or pod or cluster or pod.
- For a root admin, ListZones lists all zones including the 'Disabled' zones. But for any other user, the 'Disabled' zones are not included in the response.
- For any usecase that creates/deploys/adds/registers a resource and takes in zone as parameter, now we check if the Zone is 'Disabled'. If yes then the operation cannot be performed by a user other than root-admin. Add volume, snapshot, templates are examples of this usecase.
- To enable the root admin to test a particular pod/cluster/host, deployVM command takes in 'host_id' parameter that can be passed in only by root admin.
If this parameter is passed in by the admin, allocators do not search for hosts and use that host only. StoragePools are searched in the cluster of that host.
If VM cannot be deployed to that host, allocators and deployVM fails without retrying
two issues here:
1. in some case, two sequent commands are sent out at the same time.
2. before starting a user VM , make sure domr is up
status 9024: resolved fixed
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
alena
Alex Huang
Sheng Yang
Edison Su
Frank
Abhinandan Prateek
anthony
kishan
Chiradeep Vittal
Jessica Wang
prachi
Kelven Yang
nit
Prasanna Santhanam
Murali Reddy
will