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>
If you shut down the agent while VMs are running, the management
server assumes that the VMs are continuing to run. You can then
delete the host while it is in 'disconnected' state, and those VMs
will be unusable, forever in running state. They can't change state
because the host no longer exists. This patch checks for any VMs
that may have been tied to the removed host and resets their state
so that cloudstack can continue to manage them.
This is due to a VM on zone wide primary storage not requiring storage migration while migrating across clster.
Detecting the storage pool type before allowing normal migration (without storage live migration) of VM across cluster.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
Changes:
- Added null check around clusterId, since its possible to have null clusterId for storagepool and host records
Conflicts:
server/src/com/cloud/capacity/CapacityManagerImpl.java
Changes:
- When listing a zone, add clause in the search to check the account_id for a dedicated zone
- When listsing a zone with a domainid, add a similar clause.
- DomainCheck:: checkAccess() for a zone should consider that zone can now be dediacted to a specific account and check access accordingly.
This reverts commit 94254e3c2b.
Conflicts:
server/src/com/cloud/configuration/ConfigurationManagerImpl.java
Regular user should be able to list the network offering with specifyVlan=true. He just can't use when create the network as he is unaware of the physical network topology. But as the admin can create the network on the user's behalf using this kind of offering, so the user should be able to see the offering's details
ASF 4.1 to 4.2 Upgrade: Missing Global Configuration parameters on the Upgraded Setup related to "storage.cache". Adding them
Signed off by : nitin mehta<nitin.mehta@citrix.com>
Changes:
createZone API:
- This API takes in domainid, set it to the zone record in the data_center table
updateZone API:
- This API uses 'isPublic' flag to set a private zone to public - if this flag is set and the zone is dedicated, release the dedication and remove the domainid from the data_center table
listZone API:
- This API already has 'domainid' parameter. We should allow list zones by domain for Root admin.
DedicateZone API:
- set domainid in the data_center table
ReleaseDedicatedZone API:
- remove zoneid from the data_center table
only when there is portable IP range added at region level.
region response will now have details if portable IP service is enabled
or not. Portable IP service for a region is turned off by default. when
adming adds a portable ip range portable ip service is enabled for the
region.
Changes:
- Implict creation of the 'ExplicitDedication' Affinity group during resource dedication
- Only one group per account or per domain will be present
- ListDedicatedResources by affinityGroup
- Deployment should consider dedicated resources associated to the group only
- Deleting affinity group should release the dedicated resouces
- Releasing the dedicated resources should remove the group associated if there are no more resources.
Changes:
- 'ExcplicitDedication' type of group can be created/deleted by Root admin only
- Users can no longer create this type of affinity group
- RootAdmin can create this type of affinitygroup at domain level. Such a domain level group is available for all accounts in that domain for listing and for use during deployVM.
- The domain level affinitygroup should be visible to the users in that domain, domain admins and Root admin.
Updating the new system template URLs for the existing templates during upgrade to 4.2.
If new 4.2 system template is registered before upgrade then marking the old templates as removed during upgrade.
Sateesh Chodapuneedi
Kelven Yang
Marcus Sorensen
Min Chen
Anthony Xu
Bharat Kumar
Nitin Mehta
Prachi Damle
Alena Prokharchyk
Mike Tutkowski
Fang Wang
Vijayendra Bhamidipati
Edison Su
Wei Zhou
Kishan Kavala
Likitha Shetty
frank
Jessica Wang
Saksham Srivastava
Murali Reddy
Rajesh Battala
Devdeep Singh
Harikrishna Patnala