Description:
Simpler fix to support upgrade path from 4.1.1 to 4.2.0
by adding a 4.1.1 string in the db update version range.
Commit # d1642a489c introduced a duplicate
user_vm_view view in the schema-410to420.sql script. Removing the first
occurrence of that view, since whatever QA has been testing until now
would have used the duplicated view that gets created after the first one.
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.
(cherry picked from commit 07d79c7ad6)
Signed-off-by: animesh <animesh@apache.org>
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.
(cherry picked from commit 0b9b36cbca)
Signed-off-by: animesh <animesh@apache.org>
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)
(cherry picked from commit 61ebfad449)
Signed-off-by: animesh <animesh@apache.org>
MySQLIntegrityConstraintViolationException while performing any task
using local storage after upgrade from 3.0.7 to 4.2.(cherry picked from commit 21cb33a02c)
Signed-off-by: animesh <animesh@apache.org>
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>
(cherry picked from commit 808183fdcc)
Signed-off-by: animesh <animesh@apache.org>
This was reverted by 0a5228922b unintentionnaly
but broke this feature for RBD.
Enable SystemVM deployment on RBD again
(cherry picked from commit 3315159de6)
Signed-off-by: animesh <animesh@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
(cherry picked from commit a0de0d0177)
Signed-off-by: animesh <animesh@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>
Vijayendra Bhamidipati
Min Chen
Kelven Yang
Wei Zhou
Prachi Damle
bharat kumar
Edison Su
Sateesh Chodapuneedi
Wido den Hollander
Sanjay Tripathi
Animesh Chaturvedi
frank
Kishan Kavala
Alena Prokharchyk
Edison Su