GabrielBrascher opened a new pull request #5410: URL: https://github.com/apache/cloudstack/pull/5410
### Description This PR fixes issue #5407. In summary, volumes that should not be migrated are still being mapped in `VirtualMachineManagerImpl.createStoragePoolMappingsForVolumes`. To give some context: method `createStoragePoolMappingsForVolumes` is used only when migrating a VM with its volume(s), therefore via the API call [migrateVirtualMachineWithVolume](https://cloudstack.apache.org/api/apidocs-4.15/apis/migrateVirtualMachineWithVolume.html). In such cases, there are two options: A. User does not provide volumes, just the VM ID, and Host ID B. User provides VM ID, Host ID, and a volume map, e.g. `migrateto[0].volume=71f43cd6-69b0-4d3b-9fbc-67f50963d60b&migrateto[0].pool=a382f181-3d2b-4413-b92d-b8931befa7e1&migrateto[1].volume=88de0173-55c0-4c1c-a269-83d0279eeedf&migrateto[1].pool=95d6e97c-6766-4d67-9a30-c449c15011d1`. However, regardless of case A or B, `createStoragePoolMappingsForVolumes` iterates all the VM's volumes and adds to be migrated. Therefore, this causes exceptions when migrating VMs with data disk attached whenever the data-disk (shared) should not be migrated. From my point of view, it does not make sense to add volumes that the user has not mapped to be migrated unless the VM is migrated to **(I)** different cluster or **(II)** the volume scope is LOCAL. Both of these cases are already covered by the if statement previous to the removed line in this PR. ``` if (ScopeType.HOST.equals(currentPool.getScope()) || isStorageCrossClusterMigration(plan.getClusterId(), currentPool)) { createVolumeToStoragePoolMappingIfPossible(profile, plan, volumeToPoolObjectMap, volume, currentPool); } ``` <!--- Describe your changes in DETAIL - And how has behaviour functionally changed. --> <!-- For new features, provide link to FS, dev ML discussion etc. --> <!-- In case of bug fix, the expected and actual behaviours, steps to reproduce. --> <!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be closed when this PR gets merged --> <!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" --> <!-- Fixes: # --> <!--- ********************************************************************************* --> <!--- NOTE: AUTOMATATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE DOCUMENTATION. --> <!--- PLEASE PUT AN 'X' in only **ONE** box --> <!--- ********************************************************************************* --> ### Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [X] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) ### Feature/Enhancement Scale or Bug Severity #### Feature/Enhancement Scale - [ ] Major - [ ] Minor #### Bug Severity - [ ] BLOCKER - [X] Critical - [ ] Major - [ ] Minor - [ ] Trivial ### How Has This Been Tested? <!-- Please describe in detail how you tested your changes. --> <!-- Include details of your testing environment, and the tests you ran to --> <!-- see how your change affects other areas of the code, etc. --> Migrate VM with Root disk in local storage. Tests have been done via the UI as well as the API. Also, it considered on both cases: A. User does not provide volumes, just the VM ID, and HostID; B. User provides VM ID, and HostID, and a volume map, e.g. `migrateto[0].volume=71f43cd6-69b0-4d3b-9fbc-67f50963d60b&migrateto[0].pool=a382f181-3d2b-4413-b92d-b8931befa7e1&migrateto[1].volume=88de0173-55c0-4c1c-a269-83d0279eeedf&migrateto[1].pool=95d6e97c-6766-4d67-9a30-c449c15011d1`. In both cases, the volume map has been done accordingly with the expected behavior. VMs that fail to be migrated, have been successfully migrated and only the correct volume was migrated; data disks remained attached to the VM, at their storage pool, and in "Ready" state. <!-- Please read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md) document --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
