DB schema changes to support this feature.
Added 3 new tables.
'vmware_data_center' to persist information about each Vmware datacenter known to cloudstack.
'vmware_data_center_zone_map' to persist mapping information of a Vmware datacenter & cloudstack zone.
'legacy_zones' to persist the known legacy zones in the deployment.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Introduced 2 new API command classes AddVmwareDcCmd & RemoveVmwareDcCmd.
The new APIs are addVmwareDc & removeVmwareDc, these APIs will associate a Vmware datacenter to a cloudstack zone & dis-associate a Vmware datacenter from a cloudstack zone.
Constraint checks are added for infrastructure change operations in zone that encompass resources like clusters.
Constraint checks are added in discoverer and manager classes.
Added a service 'VmwareDatacenterService' to expose methods that will have API implementation for 2 APIs addVmwareDc & removeVmwareDc
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Support for DB changes for Vmware datacenter objects
Support for DB changes to store mapping with CloudStack zones.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Patch 2 for https://reviews.apache.org/r/11379/
Created for files server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java, server/test/com/cloud/vm/DeploymentPlanningManagerImplTest.java, server/test/org/apache/cloudstack/affinity/AffinityApiUnitTest.java
This feature allows a user to deploy VMs only in the resources dedicated to his account or domain.
1. Resources(Zones, Pods, Clusters or hosts) can be dedicated to an account or domain.
Implemented 12 new APIs to dedicate/list/release resources:
- dedicateZone, listDedicatedZones, releaseDedicatedZone for a Zone.
- dedicatePod, listDedicatedPods, releaseDedicatedPod for a Pod.
- dedicateCluster, listDedicatedClusters, releaseDedicatedCluster for a Cluster
- dedicateHost, listDedicatedHosts, releaseDedicatedHost for a Host.
2. Once a resource(eg. pod) is dedicated to an account, other resources(eg. clusters/hosts) inside that cannot be further dedicated.
3. Once a resource is dedicated to a domain, other resources inside that can be further dedicated to its sub-domain or account.
4. If any resource (eg.cluster) is dedicated to a account/domain, then resources(eg. Pod) above that cannot be dedicated to different accounts/domain (not belonging to the same domain)
5. To use Explicit dedication, user needs to create an Affinity Group of type 'ExplicitDedication'
6. A VM can be deployed with the above affinity group parameter as an input.
7. A new ExplicitDedicationProcessor has been added which will process the affinity group of type 'Explicit Dedication' for a deployment of a VM that demands dedicated resources.
This processor implements the AffinityGroupProcessor adapter. This processor will update the avoid list.
8. A VM requesting dedication will be deployed on dedicatd resources if available with the user account.
9. A VM requesting dedication can also be deployed on the dedicated resources available with the parent domains iff no dedicated resources are available with the current user's account or
domain.
10. A VM (without dedication) can be deployed on shared host but not on dedicated hosts.
11. To modify the dedication, the resource has to be released first.
12. Existing Private zone functionality has been redirected to Explicit dedication of zones.
13. Updated the db upgrade schema script. A new table "dedicated_resources" has been added.
14. Added the right permissions in commands.properties
15. Unit tests: For the new APIs and Service, added unit tests under : plugins/dedicated-resources/test/org/apache/cloudstack/dedicated/DedicatedApiUnitTest.java
16. Marvin Test: To dedicate host, create affinity group, deploy-vm, check if vm is deployed on the dedicated host.
normally, in dhcp reply, the target ip is allocated ip for VM.
but windows 2008 32bit has special field in dhcp reply, which makes dhcp reply use 255.255.255.255 as target ip, which is blocked by SG rule,
An extra public ip is acquired while implementing the vnmc element as there is a limitation where in the source nat cannot be used as asa outside ip.
As a result of this when the network gets re-implemented an additional ip is acquired every time. The fix involves checking for existing public ips
in the network and reuse it in case it is not a source nat ip for assigning to asa outside interface.
Sateesh Chodapuneedi
Kishan Kavala
radhikap
Pranav Saxena
Nitin Mehta
Saksham Srivastava
Mice Xia
Prasanna Santhanam
Ashutosh
Prachi Damle
Anthony Xu
Sheng Yang
Murali Reddy
Koushik Das
Chiradeep Vittal
Jessica Wang
Min Chen
Alena Prokharchyk