Mapping model for CloudStack zone and Vmware datacenter

Bug Reference

https://issues.apache.org/jira/browse/CLOUDSTACK-1963

Branch

master, 4.2.0

Introduction

In today's implementation, vSphere DC is invisible to CloudStack, we allow multiple clusters (vSphere DC) even from different vCenter instances to be added to CloudStack zone.

Issues:-
1) Multiple vCenter instances in same cloudstack zone.
2) Multiple vmware DCs in same cloudstack zone.
3) 1:1 mapping of cluster to vmware DC - recommended due to chance of having multiple cloudstack deployments in same DC
3a) 1:1 mapping of Nexus switch to cluster
3b) 1:1 mapping of ASA with cluster
4) vDS - enforced override of zone wide traffic label not required in case of multiple DCs in zone.

Purpose

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

References

http://www.vmware.com/pdf/vsphere5/r51/vsphere-51-configuration-maximums.pdf
http://www.vmware.com/pdf/vsphere5/r50/vsphere-50-configuration-maximums.pdf
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_config_max.pdf

Document History

Glossary

DC - VMware vCenter Data Center.
N1kv - Cisco Nexus 1000v Distributed Virtual Switch
vDS - VMware vNetwork Distributed Virtual Switch.
vSwitch - VMware vNetwork Standard Virtual Switch
dvPortgroup - VMware vNetwork Distributed Virtual Portgroup
Portgroup - VMware vNetwork Standard Virtual Portgroup

Feature Specification

With this feature, Vmware datacenter will be put under management of CloudStack zone.
In previous releases, Vmware datacenter is hidden behind a CloudStack cluster, we need an explicit mapping policy for Vmware datacenter both
for zone-wide storage and zone-wide network resources. This makes datastore in a DC to span across clusters scoped by cloudstack zone. Also this means dvSwitch in DC spans across clusters in the zone. VM live migration across clusters in zone can be realized with this model.

Test Guidelines

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. 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.

Supportability characteristics

Logging

VMware hypervisor plugin logs all the successful operations to INFO, all exceptions/failures to ERROR, and all synchronization checks to DEBUG.

Debugging/Monitoring

In addition to looking at the management server logs, administrators can look up the vcenter logs for analysis.

Use cases

It allows the system administrator to configure cloudstack zone per DC to manage all the the resources in DC.

• All DC wide features would be available across cloudstack zone.
• Zone wide virtual network orchestration is supported using distributed virtual switch (VMware DVS, Nexus 1000v DVS)
• Zone wide storage/datastore.

Architecture and Design description

Vmware datacenter will be put under management of CloudStack zone.

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.

CloudStack manages resources at the level of DC.

1. Datastores
   1. Zone wide, Cluster wide, Host wide
2. vDS
   1. Zone wide guest/public networks.
   2. Pod wide private network.
3. Nexus 1000v DVS
4. Clusters

Database modifications

1. data_center_details table will be used to populate a key value pair (key: vmwaredc) to store DC associated with zone.

Web Services APIs

1. AddCluster will be modified
   1. Make vCenter credentials optional based on vmwaredc key's presence in data_center_details.

UI Flow

• Changes required in UI for live migrating a volume from one storage pool to another.
  1. Add Cluster form in zone wizard
  2. Add Cluster wizard
  3. Add NexusVSM instance to zone
  4. Add ASA instance to zone

Open Issues

1. Single DC will NOT be allowed to be managed by multiple cloudstack deployments. Name space collision issues within DC will be resolved by this.
2. Nexus support needs changes. 1 cluster to 1 Nexus mapping to be removed. Allow Nexus 1000v VSM instance to be added to zone/DC.
3. Impact of (1) on ASA feature needs check.
4. Impact of this feature on refactoring in Vmsync.

Upgrade

1. Migration support
   1. Old customers - Existing cloudstack deployments with multiple DC's in a zone
      1. Decide a DC as the final DC that contains all clusters.
      2. Move all clusters to the chosen DC.
      3. For each cluster create cluster with same name in target DC.
      4. Edit dc name to match that of chosen DC where ever the dc name is present (Ex: 'guid' field in hosts table)
      5. Cold migrate each of the instance to this new cluster in chosen DC.
   2. New customers - Existing VMware deployments with clusters to be managed by cloudstack spread in multiple DC's
      1. Move all clusters meant for single zone into 1 DC
      2. For each cluster create cluster with same name in target DC.
      3. Put each host, in that cluster, in maintenance mode
      4. Remove each host in maintenance mode from the cluster
      5. Add each host to new cluster in target DC
         1. Get the host out of maintenance mode