Changes:
- Implict creation of the 'ExplicitDedication' Affinity group during resource dedication
- Only one group per account or per domain will be present
- ListDedicatedResources by affinityGroup
- Deployment should consider dedicated resources associated to the group only
- Deleting affinity group should release the dedicated resouces
- Releasing the dedicated resources should remove the group associated if there are no more resources.
Changes:
- 'ExcplicitDedication' type of group can be created/deleted by Root admin only
- Users can no longer create this type of affinity group
- RootAdmin can create this type of affinitygroup at domain level. Such a domain level group is available for all accounts in that domain for listing and for use during deployVM.
- The domain level affinitygroup should be visible to the users in that domain, domain admins and Root admin.
The time increased due to the newly added dedicated resources feature. During regular VM deployment, all dedicated resources are put in avoid list so that they are not considered for deployment.
Now the way to compute the list of dedicated resources is not optimal and performance deteriorates in an environment having lot of pods, clusters and hosts as the logic is to query db. for each suc resource.
The fix is to optimize the logic not to loop through all resources but get the list of each resource type in a single query.
with responses on other systemVm apis. All systemVM apis return
SystemVmResponse - rebootSystemVm, stopSystemVm etc. MigrateSystemVm is
now made uniform.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
domain users
Since the basic zone network is owned by 'Root' domain, domain access
checkers will fail for the accounts in non-root domains while acquiring
public IP. So add an exception for the 'Basic' zone shared network with
EIP/ELB service.
Removing memoryovercommitratio and cpuovercommitratio parameters from addCluster and updateCluster APIs,
since these can be configurable using updateConfiguration API at cluster level.
By default while creating cluster these values are taken from global configuration parameters.
Conflicts:
server/src/com/cloud/resource/ResourceManagerImpl.java
Changes:
- Locking the group and save reservation mechanism done by DPM
- Added admin operation to cleanup VM reservations
- DPM will also cleanup VM reservations on startup
- Move vnetBridge clean up function from LibvirtComputingResource to BridgeVifDriver
-- since only BridgeVifDriver have to handle this event
- LibvirtComputingResource now properly call VifDriver.unplug() when it receives UnPlugCommand
- Remove not working and no longer used method getVnet(String) from VirtualMachineName
- Remove not working and no longer used method getVnet() from StopCommand
- Remove unused constructer StopCommand(VirtualMachine, String, boolean) from StopCommand
- Remove unused member vnet from StopCommand
- Remove unused member _modifyVlanPath from OvsVifDriver
Tested with 2 KVM hosts and confirmed it correctly manipulate vnetBridge with start, stop, migrate, plug, and unplug event
Signed-off-by: Hugo Trippaers <htrippaers@schubergphilis.com>
Prachi Damle
Koushik Das
Alena Prokharchyk
Likitha Shetty
Murali Reddy
Wei Zhou
Sateesh Chodapuneedi
Jessica Wang
Min Chen
Bharat Kumar
Harikrishna Patnala
Kishan Kavala
Isaac Chiang
Jonathan Creasy
Mice Xia
Prasanna Santhanam
Rajesh Battala
frank
Edison Su
Saksham Srivastava
Ian Duffy
Toshiaki Hatano
Edison Su