Also fixed a couple of other problems:
* verify security group ids before vm creation
* don't create "default" security group (if missing) as a part of deployVm process when vm is deployed from vmWare template
Conflicts:
server/src/com/cloud/network/security/SecurityGroupManagerImpl.java
server/src/com/cloud/vm/UserVmManagerImpl.java
status 9873: resolved fixed
Following fixes were made as a part of the checkin:
* When deploy user vm and default SG doesn't exist in the DB, create it automatically.
* SecurityGroup enabled use vm start: if map to default group is not present in security_group_vm_map table, create one.
* Added "name" (securityGroupName) parameter back to deleteSecurityGroup/authorizeSecurityGroupIngress/deployVm. Mutually exclusive with security group id parameter.
status 9693: resolved fixed
2 more fixes with this commit:
* bug 9692 is fixed - we don't increment resource count when Direct ip address is allocated.
* as a part of 2.2.2->2.2.4 upgrade resource_count for public_ip records is recalculated - count only Virtual Ip addresses
- 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
alena
keshav
Alex Huang
kishan
Kelven Yang
prachi
anthony