xs 6.1/6.2 introduce the new virtual platform, so there are two virtual platforms, windows PV driver version must match virtual platforms,
this patch tracks PV driver versions in vm details and template details.
Anthony
list Clusters/pods/zones API not accounting for reserved in the used capacity percentage.
Fix listCapacity cmd for reserved as well
Signed off by : nitin mehta<nitin.mehta@citrix.com>
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.
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>
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>
(cherry picked from commit 808183fdcc)
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>
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>