Reviwed-by: Kelven Yang <kelven.yang@citrix.com>
Description:
Change the criterion for overriding/preserving the vmware.create.full.clone
flag. The earlier criterion was simply the version numbers, but that is not
a good business logic basis for the change. With this fix, if past version
deployments have any deployments (data centers), this flag will be set to
false. Else, it will be set to true.
Changes:
- In the upgrade path, for a private zone, entry needs to be added in the affinity_group_domain_map to provide access to the private zone for the domains it belongs too.
On a fresh environment, some values in cloud.configuration table are persisted in com.cloud.server.ConfigurationServerImpl.persistDefaultValues()
A default value need to be set before com.cloud.upgrade.DatabaseUpgradeChecker
(cherry picked from commit 1a67750cb6)
While upgrading to 4.2 to support existing clusters working over standard vswitch or nexus dvswitch should be supported as is. To ensure this while upgrading to 4.2, existing cluster's vswitch configuration needs to be persisted to database. If zone level traffic label is empty then default vswitch name would be used.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
CLOUDSTACK-4457:
CLOUDSTACK-4459:
harden kvm getvolume. It's possible that one volume created on other kvm host, won't show up on another host, try more times to refresh storage pool if volume won't shown up
Currently zones with multiple clusters from more than 1 hypervisor including VMware, are being ignored while processing them during upgrade.
If a zone has all non-VMware clusters then ignoring the zone is correct.
But if a zone has atleast 1 VMware cluster then make sure the zone processed further to mark it as legacy or associate the zone with appropriate VMware DC.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
While upgrading to 4.2, the type of vswitch being used by each cluster is persisted to cluster_details table. This helps if user want to change the type of vswitch used in a zone or entire cloud later on but leave existing cluster continue to use old vswitches. Hence even after modifying the type of vswitch at cloud level (by modifying global configuration parameters) or modifying the type vswitch at zone level (by modifying the traffic label) would not disturb operation of existing clusters.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Builtin template Ready Status is No even after the Status is downlaod complete. The reason was that template sync updates only the template download state but not the state. Fixing that. Ideally we should change the state through state machine only.
Signed off by : nitin mehta<nitin.mehta@citrix.com>