Page History

...

1. 'cloud'.'vmware_data_center' table to track all DC specific information along with details of resources & vCenter.
   1. Columns in this table are id, DC name, guid. The 'guid' field encapsulates 'vCenter host/ip' and DC mor. E.g. 'vcenter.abc.com@dc-101'
   2. id is primary key field of this table
   3. Implement Dao & VO for this table.
   4. Schema definition
      1. CREATE TABLE `cloud`.`vmware_data_center` (
         `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
         `name` varchar(255) NOT NULL COMMENT 'id of CloudStack zone',
         `guid` varchar(255) NOT NULL UNIQUE COMMENT 'id of VMware datacenter',
         PRIMARY KEY (`id`) ENGINE=InnoDB DEFAULT CHARSET=utf8;
2. 'cloud'.'zone_vmware_data_center_map' table will be added to persist the mapping of zone to DC.
   1. Columns in this table are id, vmware_dc_id, zone_id
   2. Foreign key id from vmware_dc table
   3. Foreign key id from data_center table
   4. Implement Dao & VO for this table.
   5. Foreign key zone_id from data_center table.
   6. Schema definition
      1. CREATE TABLE `cloud`.`zone_vmware_data_center_map` (
         `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
         `zone_id` bigint unsigned NOT NULL UNIQUE COMMENT 'id of CloudStack zone',
         `vmware_data_center_id` bigint unsigned NOT NULL UNIQUE COMMENT 'id of VMware datacenter',
         PRIMARY KEY (`id`),
         CONSTRAINT `fk_zone_vmware_data_center_map__zone_id` FOREIGN KEY (`zone_id`) REFERENCES `data_center`(`id`) ON DELETE CASCADE,
         CONSTRAINT `fk_zone_id` FOREIGN KEY (`zone_id`) REFERENCES `data_center`(`id`) ON DELETE CASCADE_vmware_data_center_map__vmware_data_center_id` FOREIGN KEY (`vmware_data_center_id`) REFERENCES `vmware_data_center`(`id`) ON DELETE CASCADE
         ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
3. 'cloud'.'legacy_zones' table to track legacy zones in cloudstack deployment. During CloudStack upgrade, this table is populated.
   1. Columns in this table are id, zone id
      1. id is primary key field of this table
      2. Foreign key zone_id refers id from data_center table
   2. Schema definition
      1. CREATE TABLE `cloud`.`legacy_zones` (
         `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
         `zone_id` bigint unsigned NOT NULL UNIQUE COMMENT 'id of CloudStack zone',
         PRIMARY KEY (`id`),
         CONSTRAINT `fk_zone_vmware_data_center_map__vmwarezone_data_center_id` FOREIGN KEY (`vmware_data_center`zone_id`) REFERENCES `vmware_data`data_center`(`id`) ON DELETE CASCADE
         ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

...

1. Impact of this feature on zone wide primary storage support - vmware.
2. Impact of this feature on storage live migration - vmware.
3. 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.
4. Impact of this feature on ASA feature needs check.
5. Impact of this feature on refactoring in Vmsync.

Upgrade

1. During CloudStack upgrade operation, 'cloud'.'legacy_zones' table is populated. This table will legacy zones in cloudstack deployment.
2. Migration support
   1. Existing CloudStack deployments with clusters from multiple DCs/vCenters require consolidation of clusters into single DC.
   2. Following are options to migrate VM across datacenters
      1. Cold migrate each of the instance to this new cluster in chosen DC.
      2. Hot migrate the VMs by using disconnecting all hosts from source cluster followed by deletion of source cluster from source DC and adding all hosts to cluster in target DC.
      3. Hot migrate the VMs after suspending the VMs. Need to power on (mean resume) VMs after migration is complete. This needs the virtual disks of VM to be placed on shared storage before triggering the migration operation.
   3. Pre-requisite checker tool - This tool should go through existing CloudStack deployment and VMware deployment to check if prerequisites are met. Following are list of prerequisites would be convered during upgrade to new version of product with this feature built-in,
      1. A CloudStack zone should encompass only 1 VMware DC
      2. The VMware DC encompassed by CloudStack zone should not be shared by multiple CloudStack deployments.
3. Guidelines of CloudStack version upgrade
   1. Migration would be offline operation before CloudStack version upgrade operation.
   2. Prerequisite checker tool would be run as part of CloudStack upgrade
   3. Choice of migration procedure is above option 1.b.(2ii) - migration of host across DC by disconnecting from cluster in source DC, followed by connecting it to target cluster in another DC. Following are detailed steps,
      1. Handle the case of clusters from multiple vCenter
         1. To be investigated.
      2. Handle the case of clusters from single vCenter but different DCs
         1. Handle the case of deployment using distributed virtual switch (Nexus 1000v or vDS)
            1. Deploy Nexus 1000v or vDS on target DC with same credentials (user/password)
            2. Ensure if 'cloud'.'virtual_supervisor_module' table has the new IP of Nexus 1000v VSM instance.
            3. Create all dvPortgroups required by VMs on the host that is moving across DCs. Make sure all properties of dvPortGroups are in sync, e.g. shaping policy should be same as that of original dvPortGroup in source DC. External switch configuration for trunking/routes is assumed to be taken care of by admin.
      3. Decide a DC as the final DC that contains all clusters.
      4. Create a cluster, in target DC, with same properties as that of original cluster
      5. Unmanage the cluster in CloudStack
      6. Disconnect each host in source cluster
      7. Remove each host from source cluster
      8. Add each host to target cluster
      9. Create all custom properties
         1. Each VM will have custom properties like cloud.nic.mask. This will be lost during above migration operations. Hence need to re-create after adding to target cluster
         2. Each template (user VM and system VM templates) will have custom properties like cloud.uuid. This need to be restored.
      10. Add the target cluster to CloudStack
      11. Make sure that guid field of 'cloud'.'host' table has the valid reference because when host is added to target cluster, it will acquire new unique reference.
      12. Make sure the field 'cloud'.'cluster'.'name' in database reflect new DC name in cluster name.
      13. Make sure the field 'cloud'.'cluster_details'.'url' in database reflect new DC name in cluster name.

...