Skip to content

Find suitable storage for migration regression #4400

Description

@borisstoyanov
ISSUE TYPE
  • Bug Report
COMPONENT NAME
VMware migration, API
CLOUDSTACK VERSION
4.14
CONFIGURATION

VMware

SUMMARY

When executing the api agains attached volume we observe that none of the pools is marked suitable, a little investigation was done suspecting the following change:
https://github.com/shapeblue/cloudstack/blob/ovfprops-and-vsphere-adv-together/server/src/main/java/com/cloud/server/ManagementServerImpl.java#L156

        //This is an override mechanism so we can list the possible local storage pools that a volume in a shared pool might be able to be migrated to
diskProfile.setUseLocalStorage(true);

Before searching for the suitable storage pools, volume is marked as using local storage just to also find any local storage pools to which volume can be migrated along with the shared storage pools.

But this is causing regression for zone wide storage pools, while zone wide storage pool allocator searches for any zone wide storage pools the entrance check is

if (dskCh.useLocalStorage()) { return null;} which causing zone wide storage pool allocator returning nothing and at the end findStoragePoolsForMigration API shows all zone wide storage pools are “not suitable“.

Below is the screenshot of a volume which is not associated with any storage policy but still showing “vvol5-zone“ as “not suitable“.
image-20201011-195301

Activity

  1. sureshanaparti commented on Oct 13, 2020

    @sureshanaparti
    Contributor

    @borisstoyanov the check in the Zone wide pool allocator if (dskCh.useLocalStorage()) { return null;} should be ok, as the local storage can never be a zone wide pool and the disk profile want to find suitable local storage pools only, as the flag useLocalStorage is set. "useLocalStorage" should be appropriately set to find the local pools only, for zone / cluster-wide pool, this flag should be set to false.

  2. sureshanaparti commented on Nov 20, 2020

    @sureshanaparti
    Contributor

    The override mechanism to list the possible local storage pools is skipping the zone wide pools, and so when migrating a volume attached to a running VM doesn't list zone wide pool as a suitable pool in UI, with findStoragePoolsForMigration API.

    To fix this and consider zone wide pools for migration, the condition if (dskCh.useLocalStorage()) { return null;} has to be removed from ZoneWideStoragePoolAllocator. This is already addressed in PR #4304

  3. harikrishna-patnala commented on Nov 20, 2020

    @harikrishna-patnala
    Member

    @sureshanaparti if we remove the local storage condition from ZoneWideStoragePoolAllocator then it implies that any volume on local or cluster scoped or zone wide storage can be migrated to zone wide storage. If those operations are functionally allowed then the fix that you mentioned is fine.

    Can you please confirm if volumes on any storage(local, cluster, zone) can be migrated to zone wide storage.

  4. sureshanaparti commented on Nov 20, 2020

    @sureshanaparti
    Contributor

    @harikrishna-patnala the intention is to list all the storage pools and mark as suitable / unsuitable. If unsuitable pool is selected for migration, the appropriate cmd is sent to hypervisor resource for migration. If succeeds, the offering, etc. applicable details are updated, else keeps the same.

    Please take a look at the actual implementation in the PRs: #2425 and #2486.

    The override mechanism in these changes is skipping the zone wide pools, which are also has to be considered. In order to consider these, that cond. have to be removed. Otherwise, there is no way to migrate to zone wide pool using findStoragePoolsForMigration API from UI.

  5. rafaelweingartner commented on Jan 5, 2021

    @rafaelweingartner
    Member
  6. DaanHoogland commented on Feb 1, 2021

    @DaanHoogland
    Contributor

    @borisstoyanov can you check in 4.15?
    also the link in the summary gives me a 404, can you update the description, please?

  7. added this to the 4.16.0.0 milestone on Feb 5, 2021
  8. DaanHoogland commented on Feb 5, 2021

    @DaanHoogland
    Contributor

    marking 4.16 as #4304 is as well

  9. added a commit that references this issue on Feb 25, 2021
    88337bd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions