Page History

...

1. Vmware datacenter will be put under management of CloudStack zone.
2. In this explicit model, CloudStack will understand the relationship between a Vmware datacenter and resources underneath it, so when resources like a Vmware cluster or dvSwitch that is added to CloudStack, the underlying Vmware resource relationship between these objects will become constraint information for CloudStack to use. For example, a Vmware cluster can't be added to a CloudStack zone if it's Vmware DC is not under the CloudStack zone, also an ASA instance cannot be added to a Vmware cluster that its Vmware DC is not in the zone. The model itself will not limit how many Vmware clusters that a N1kv VSM instance or ASA or vDS will manage, as long as N1kv or ASA or vDS and its managed cluster are within the same Vmware DC.
3. CloudStack should be able to add/manage following DC level resources in scope of zone.
   1. Clusters
   2. Datastores for zone wide storage
   3. Distributed virtual switches for zone wide virtual networks.
      1. Nexus 1000v DVS
      2. VMware DVS - this is already realized by zone wide traffic labels.
4. Constraint checks
   1. Only clusters of the associated DC can be added to a zone.
      1. Retrieve name of DC which encompasses this cluster. Compare the retrieved DC name with name of DC (being) associated with this zone.
   2. DC is not associated with any other zone already.
      1. Check guid, of new DC being added, doesn't already exist in table 'cloud'.'zone_vmware_data_center_map'. The guid is a string that encapsulates MOR of DC and vCenter host name/ip. By tracking both vCenter host name/ip and MOR of DC, it's possible to distinguish DC's across multiple vCenters.
      Only N1kv VSM of the associated DC can be added to a zone.
      1. N1kv's vCenter server connection's properties would need to be checked to retrieve the association of N1kv with a vCenter and a DC. Compare the retrieved vCenter IP and DC name with vCenter IP and DC name of current zone
   3. DC is not associated with any other zone alreadycloudstack deployment.
      1. Check guid, of new DC being added, doesn't already exist in table 'cloud'.'data_center_zone_map'. The guid is a string that encapsulates MOR of DC and vCenter host name/ip. By tracking both vCenter host name/ip and MOR of DC, it's possible to distinguish DC's across multiple vCenters.
   4. DC is not associated with any other cloudstack deployment.
      1. Check custom property over VMware's DC object if this DC is already associated with a zone of a cloudstack deployment. Custom property of type boolean can represent this, 'cloudstackzone'
   5. 1. custom property over VMware's DC object if this DC is already associated with a zone of a cloudstack deployment. Custom property of type boolean can represent this, 'cloudstackzone'
5. While While adding resource to cloudstack zone, approaches to apply constraint checks are,
   1. Track relationship between resources (DC <-> Cluster <> DataStore <> DVS <> N1kv <-> ASA etc.) in cloudstack database - suffices within single CloudStack deployment. Cannot detect if multiple CloudStack deployments are managing same resource (DC, DataStore etc.)
   2. Use custom property on VMware object as flag. This works across cloustack deployments but proper cleanup is required upon removal.
6. During discovery process, VmwareServerDiscoverer might have to retrieve vCenter host/ip & credentials from database given zone_id, because they are made optional parameters because this data is already available in database when the zone is associated with first cluster. Construct connection url from this data.
7. While re-loading resource make sure connection url is defined correctly, could be retrieved from vmware_data_dc center table (guid).
8. AddCluster changes
   1. If a row matches zone_vmware_dcdata_center_map.zone id and if DC name is not specified, DC name can be retrieved from vmware_dc data_center table and used. If DC name is specified, validation of DC name should happen.
   2. In VmwareServerDiscoverer, implement constraint checks while adding a cluster as mentioned in design section.
   3. Update vmware DC properties in cloud.vmware_data_dc center table (Say DC name changes in vCenter)
   4. While adding VMware cluster to zone, check if zone_vmware_data_dccenter_map is empty or not. If empty, while adding this cluster we need to associate corresponding DC to zone. Hence do following,
      1. Update tables cloud.zone_vmware_data_dccenter_map and cloud.vmware_data_dc center to associate DC with zone
      2. If N1kv instance is specified, update table cloud.virtual_supervisor_module and cloud.zone_vsm_map to assocaite N1kv VSM instance with zone
      3. Set custom property over VMware DC object. If not already present, add boolean property 'cloudstackzone' with value 'true'. If the property is already present, just set it to 'true'. Now this DC cannot be associated with any other cloudstack zone.
   5. Allow multiple N1kv VSM instances to be added to zone.
   6. Avoid cascaded removal of VSM instance upon cluster deletion as the association is now at zone level.
   7. Change cleanup code of N1kv VSM instances as cleanup should happen automatically with zone removal instead of cluster removal earlier.

1. DeleteCluster changes
   1. While deleting
   DeleteCluster changes
   1. While deleting check if this is last cluster in the zone. If so, dis-association of DC to zone should be done. Hence do following,
      1. Cleanup tables cloud.zone_dc_map and cloud.vmware_dc for specific zone by removing entries by zone_id (if zone_id in row matches data_center.id then remove the row)
      2. Set the zone's corresponding DC object's property to 'false'. Now this DC can be associated with any other cloudstack zone.

...

• Changes required in UI for live migrating a volume from one storage pool to another.
  1. Associate zone with DC
  2. Dis-associate zone with DC
  3. Support adding zone level entities (NexusVSM etc.) to zone.Add Cluster form in zone wizard
  4. Add Cluster form in zone wizard
  5. Add Cluster wizard
  6. Add NexusVSM instance to zone
  7. Add ASA instance to zone

Open Issues

Anchor
OpenIssues OpenIssues

1. Should we allow Not allowing a VMware datacenter entity to exist even though it's not associated with any cloudstack zone?

Impact on other areas/features

1. . Add/remove DC is not supported. Only associate/dis-associate are. Hope this is fine.
2. Zone doesn't contain multiple hypervisors. Is this fine?

Impact on other areas/features

1. Impact of this feature on zone wide primary storage support - vmware.
2. Impact of this feature on storage
3. Impact of this feature on zone wide primary storage support - vmware.
4. Impact of this feature on storage live migration - vmware.
5. Cisco Nexus 1000v support needs changes. 1 cluster to 1 Nexus mapping to be removed. Allow Nexus 1000v VSM instance to be associated/dis-associated with zone.
6. Impact of this feature on ASA feature needs check.
7. Impact of this feature on refactoring in Vmsync.

...

1. Mapping of Nexus VSM instance with zone
   1. Bring in new APIs to support associate / dis-associate a Nexus VSM instance with a zone
   2. While adding a cluster, let user choose which Nexus VSM to be used for virtual network orchestration. Actually Nexus VSM doesn't care about the cluster but it manages host. So to make the operation valid, it required (a pre-requisite) that all hosts in a cluster should be part of single Nexus VSM instance.
2. Allow multiple Nexus VSM instances to be associated with single cloudstack zone.to be associated with single cloudstack zone.
3. Architecture
   1. While adding a cluster, if N1kv instance is specified, update table cloud.virtual_supervisor_module and cloud.zone_vsm_map to assocaite N1kv VSM instance with zone
   2. Set custom property over VMware DC object. If not already present, add boolean property 'cloudstackzone' with value 'true'. If the property is already present, just set it to 'true'. Now this DC cannot be associated with any other cloudstack zone.
   3. Allow multiple N1kv VSM instances to be added to zone.
   4. Avoid cascaded removal of VSM instance upon cluster deletion as the association is now at zone level.
   5. Change cleanup code of N1kv VSM instances as cleanup should happen automatically with zone removal instead of cluster removal earlier.
   6. Constraint checks
      1. Only N1kv VSM of the associated DC can be added to a zone.
      2. N1kv's vCenter server connection's properties would need to be checked to retrieve the association of N1kv with a vCenter and a DC. Compare the retrieved vCenter IP and DC name with vCenter IP and DC name of current zone
4. DB changes
   1. 'cloud'.'cluster_vsm_map' would be removed.
   2. 'cloud'.'zone_vsm_map' would be added. Also a zone can be associated with more than 1 VSM instances.
   3. Columns in this table are id, zone_id & vsm_id where id is Primary key of this table.
   4. Foreign key vsm_id from virtual_supervisor_module table.
   5. Implement Dao & VO classes for this table.
   6. from virtual_supervisor_module table.
   7. Implement Dao & VO classes for this table.
5. Zone level Cisco ASA 1000v instance.
6. CloudStack should be able to add/manage following DC level resources in scope of zone.
   1. Distributed virtual switches for zone wide virtual networks.
      1. Nexus 1000v DVS
      2. VMware DVS - this is already realized by zone wide traffic labels.
7. UI Flow
   1. Support add/removal of Nexus 1000v device to a zone
   2. Support add/removal of ASA 1000v to a zone
   Zone level Cisco ASA 1000v instance
   1. .