Load non-routing resource in ClusteredAgentManager includes External DHCP, PxeServer, ExternalFirewall, ExternalLoadBalancer
Bug 9887 - baremetal: support for image operation (create template from guest disk) (edit)
changes in line with UI
Load non-routing resource in ClusteredAgentManager includes External DHCP, PxeServer, ExternalFirewall, ExternalLoadBalancer
Bug 9887 - baremetal: support for image operation (create template from guest disk) (edit)
changes in line with UI
The step to upgrade xenserver,
1. put cluster in Unmanaged state through UI , then MS will not talk to hosts in the cluster
2. upgrade xenserver according to XenServer upgrade guide.
3. put cluster in Managed state through UI, then MS will reconnect hosts
TODO,
1. UI
2. vm pool sync , leveraged from kelven's work
The step to upgrade xenserver,
1. put cluster in Unmanaged state through UI , then MS will not talk to hosts in the cluster
2. upgrade xenserver according to XenServer upgrade guide.
3. put cluster in Managed state through UI, then MS will reconnect hosts
TODO,
1. UI
2. vm pool sync , leveraged from kelven's work
Part 2
commit 797839360c65cd348d2eb20630521177ab0919de
bug 9154: redundant virtual router
commit 8ff7f230204d4d3a7a4adee75523a9a84f4276fe
bug 9154: Replace domain_router.is_master with domain_router.redundant_state in DB
commit 230b99e9e0b152648f1dd2a5eab6f22315b8e7b4
bug 9154: Add redundant state to DomainRouterResponse
commit ccefb5ff5e83d713798a347c99bce1a0d04b4317
bug 9154: Add router fault state report
commit 7a3090378f9785caecf741b70554f6ea17c41764
bug 9154: Send alert if found two virtual routers in master state
commit 66831056e4bf27665871bccd24e6159071564847
bug 9154: Code clean up
commit bf3f58a85741fa7118bd848a42d8b21baa4478d4
bug 9154: Add isRedundantRouter to DomainRouterResponse
merge createtemplateresponse and createteisoresponse
on UI template
only show template corresponding hypervisor exists
Conflicts:
api/src/com/cloud/api/ResponseGenerator.java
server/src/com/cloud/storage/StorageManager.java
status 10305: resolved fixed
While creating a system vm offering specify the type. If no type specified the default to domainrouter.
While requesting a set of system offering specify the paramter systemvmtype.
status 10305: resolved fixed
While creating a system vm offering specify the type. If no type specified the default to domainrouter.
While requesting a set of system offering specify the paramter systemvmtype.
Block update only in these cases:
* when DNS capability AllowDnsSuffixModification is false for the network
* when target network has running network elements (dhcps or domRs)
Conflicts:
server/src/com/cloud/vm/dao/DomainRouterDao.java
server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java
Block update only in these cases:
* when DNS capability AllowDnsSuffixModification is false for the network
* when target network has running network elements (dhcps or domRs)
This patch enable redundant virtual routers.
1. To enable this feature, db need to be updated using follow SQL by now(we
would get a UI way later):
UPDATE network_offerings SET redundant_router=1 WHERE guest_type="Virtual" AND
system_only=0;
2. System would try to start up two routers at different hosts. But if there is
only one host in the zone, system would start up two routers on it.
3. The failover part is using keepalived, and connection tracking part is using
conntrackd. There would be one master router and one backup router. The status
of router(master or backup) can be query from the database table domain_router
now. Management server would update the status every 30s by default.
4. The routers for the same zone would use same external NIC(same ip and mac).
The script used for fail-over would ensure only one external NIC present in the
network at any time.
5. Currently management server don't got the ability to stop one of router is
both of them reported as master. The feature is in the todo list.
After two routers start up, disconnect anyone of them, the guest network
shouldn't be affected, and established connection(http, ssh, etc.) should still
works. The fail-over on gateway part should be 3~4 seconds.
Currently the patch works with KVM. Would deal with vmware and XenServer soon.
status 9873: resolved fixed
Following fixes were made as a part of the checkin:
* When deploy user vm and 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.
Conflicts:
api/src/com/cloud/api/commands/AuthorizeSecurityGroupIngressCmd.java
api/src/com/cloud/api/commands/DeleteSecurityGroupCmd.java
api/src/com/cloud/api/commands/DeployVMCmd.java
server/src/com/cloud/api/ApiDBUtils.java
server/src/com/cloud/vm/UserVmManagerImpl.java
Changes:
- Added a new column `source_template_id` to vm_template table to carry the parent/source template ID from which the tempalte was created
- Added the column in db upgrade 224 to 225
- Changed code to save the source_template_id if there is one associated to the volume/ volume from which the snapshot was taken
- API response returns the sourcetemplateid field, if set, in all template usecases.
- CreateZone API creates a zoneToken, inserts in DB and returns it in the
response
- UpdateZone API takes in 'details' map that is loaded to data_center_details
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 9336: resolved fixed
Following changes were made:
* deleteSecurityGroup/authorizeSecurityGroupIngress - removed account/domainId parameters as SG is uniquely identified by id now
* removed account_name field from securityGroup DB table; removed allowed_security_group/allowed_sec_grp_acct from security_ingress_rule.
These values were used for api response generation only for performance purposes; added caching on API level to improve performance
* Added missing security checks for securityGroups/ingressRules
Changes:
- Cluster entry is not removed from the table when a cluster is deleted because there are some foreign key constraints failing if the row delete is attempted. Instead the cluster is marked as 'removed'
- While deleting the pod changed the check to see if pod has any clusters - we now check that there are no clusters with removed column null.
- Also pod entry cannot be deleted from the db due to foreign key constraints. So added 'removed' column to Pod table host_pod_ref
- Now on deleting a pod, the pod will be marked as removed and pod name is set to null.
Also changed 'RegisterTemplate' to take in a new optional parameter 'checksum'.
The value set to it is stored as-is in the DB in vm_template table, 'checksum' column.
1) No longer do multiple searches involving "domain" table; only one join with domain is being done.
2) Do join with domain table only when command is executed by domainAdmin
3) Added index for "path" field in "domain" table
4) No longer do joins with account table as account_id is already present in vm_instance table.
- 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
Nitin
alena
frank
anthony
Abhinandan Prateek
Sheng Yang
Murali Reddy
Alex Huang
Edison Su
will
Jessica Wang
Chiradeep Vittal
prachi