If VMware host version is ESXi 4.1 and vCenter version is 5.0 or later, number of cores per socket of a VM running on ESXi 4.1 host would be undefined as it's not supported for versions prior to 5.0.
Hence expecting undefined/null value for that and handling it.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
When master router down, the back up router is entered into FAIL state
but it supposed to enter into master.
This issue is happening because the the enable_pubip.sh script triying to
ifdown and ifup the eth2 interface. Which is failed. So master.sh script got
failed. Fixed by doing ifdown force
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>
Updating the fix to cover one more scenario when user directly calls API migrateVirtualMachineWithVolume.
If currentPool is accessible to destination host, skip calling allocators and move on to next volume to process.
This means if user calls migrateVirtualMachineWithVolume API where all volumes of VM are accessible on specified target host,
then API fails as there is no storage migration involved. Instead user should call migrateVirtualMachine API.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
listHostsForMigrationOfVM is being called when user attempts to move a VM to other host. This is trying to find list of suitable storage pools that are attached to each of the suitable hosts for the VM.
Currently the selection of target storage pools for each volume of the VM is left to storage pool allocators.
But user might want to leave his volume unmoved/intact If it is on a zone wide storage pool.
This would be more efficient while migrating VM as storage live migration is not required and VM continues to use volumes on same storage pool as before.
Hence idea is to set same storage pool as target pool for each of the volume if the volume is already on zone wide storage pool.
A comparison of source pool of volume against target pool of volume yields the information if storage migration is required for the VM to move to target host or not.
Based on that information apropriate API migrateVM or migrateVmWithVolume could be decided.
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>
KVM - Create template from volume
Vmware - Create template from volume / Create template from snapshot
send the physical size in the copycommand which accordingly will populate template store ref and the usage_event tables with the right physical size
Signed off by : nitin mehta<nitin.mehta@citrix.com>
XS Creating templates from volume - send the physical size in the copycommand which accordingly will populate template store ref and the usage_event tables with the right physical size
Signed off by : nitin mehta<nitin.mehta@citrix.com>
Introducing the option dhcp-client-update fails if the dnsmasq version is less than 2.6 (like in older templates).
Added a check for the version in cloud-early-config. will add dhcp-client-update option in the config file only
if the dnsmasq version is 2.6 and above.
Signed-off-by: Jayapal <jayapal@apache.org>
Simulator should revert back to CLOUD_DB after its operations on
SIMULATOR_DB or the cloudstack connections go to the simulator instead
of cloud.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
If all the VM's volumes are on zone wide primary storage pool then live migration of the VM would not involve storage migration. Hence MigrateVM API would be called against MigrateVMWithVolume. So far PrepareForMigrationCommand handled scenarios of VM moving across hosts within a cluster, but with zone wide primary storage in picture this command need to handle scenarios of VM moving across clusters. Try to find the VM in datacenter if not found within cluster.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Jessica
Min Chen
Vijayendra Bhamidipati
Alena Prokharchyk
Jessica Wang
Prasanna Santhanam
Sateesh Chodapuneedi
Jayapal
Gaurav Aradhye
Saksham Srivastava
Edison Su
rayeesn
Chip Childers
Sheng Yang
Anthony Xu
Rajesh Battala
Nitin Mehta
Mice Xia
Kelven Yang
Bharat Kumar
radhikap
Edison Su