Page History

...

In today's implementation, VMware DataCenter is invisible to CloudStack. CloudStack recognizes and manages cluster as resource container. There is no restriction over the DC or vCenter to which the cluster, that is being added to cloudstack zone, belongs to which DC or which vCenter instance. This implies following,

...

This document describes the specifications and design of new data model for cloudstack zone for in VMware environment.

References

...

DC - VMware vCenter Data Center.
zone - CloudStack zone.
N1kv - Cisco Nexus 1000v Distributed Virtual Switch
ASA1kv - Cisco Adaptive Security Appliance 1000v
vDS - VMware vNetwork Distributed Virtual Switch.
vSwitch - VMware vNetwork Standard Virtual Switch
dvPortgroup - VMware vNetwork Distributed Virtual Portgroup
Portgroup - VMware vNetwork Standard Virtual Portgroup

...

1. All VMware test cases need to be covered, as new mapping of DC to CloudStack zone is a change in critical path of VMware hypervisor plugin.

Hypervisor support

• VMware ESXi 4.1 or later.

Negative usage scenarios

1. Test upgrade to new product (with this feature) when the deployment already has multiple zones, where clusters in each zone encompasses one or more of following,
   1. Single DC
   2. Multiple DCs
   3. Multiple vCenters
2. After upgrade, test adding new cluster to existing zone, where the cluster belongs to a DC/vCenter that is,
3. already part of zone
4. not part of zone
5. Test new creation new zone

Hypervisor support

• VMware ESXi 4.1 or later.

Negative usage scenarios

1. A DC should not be allowed to be part A DC should not be allowed to be part of multiple CloudStack deployments.
2. In a CloudStack deployment, a DC should be associated with only one CloudStack zone.

...

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 ASA1kv instance cannot be added to a Vmware cluster that if 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 ASA1kv or vDS will manage, as long as N1kv or ASA ASA1kv 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. vDS/N1kv/ASA1kv (in future, see "Out of scope" section)
4. Following constraint checks would be done while adding DC level resource (listed above) to zone. Constraint checks
   1. Only clusters of the zone's 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.
   3. 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. While adding resource to cloudstack zone, approaches to apply constraint checks are,
   1. Track relationship between resources (DC <-> Cluster <> DataStore <-> DVS 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_center table (guid).
8. AddCluster changes
   1. If a row matches zone_vmware_data_center_map.zone id and if DC name is not specified, DC name can be retrieved from vmware_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_center table (Say DC name changes in vCenter)
   4. While adding VMware cluster to zone, check if zone_vmware_data_center_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_center_map and cloud.vmware_data_center to associate DC 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.

...