cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tutkowski, Mike" <>
Subject Re: Problem with CLOUDSTACK-10240 (Cannot migrate local volume to shared storage)
Date Mon, 16 Jul 2018 20:17:07 GMT
Allow me to correct what I said here:

“If getDefaultMappingOfVolumesAndStoragePoolForMigration is invoked, we silently ignore
the (faulty) input (which is a new storage pool) from the user and keep the volume in its
same managed storage pool (the user may wonder why it wasn’t migrated if they don’t get
an error message back telling them this is not allowed).”

I should have said the following:

If getDefaultMappingOfVolumesAndStoragePoolForMigration is invoked on a VM that is using managed
storage that is only at the cluster level (managed storage can be at either the zone or cluster
level) and we are trying to migrate the VM from one cluster to another, this operation should
fail (as the old code detects). The new code tries to keep the volume in the same storage
pool (but that storage pool will not be visible to the hosts in the destination compute cluster).

On 7/16/18, 2:10 PM, "Tutkowski, Mike" <> wrote:

    Let me answer the questions in two separate e-mails.
    This answer deals with what you wrote about this code:
        > if (destPool.getId() == currentPool.getId()) {
        >     volumeToPoolObjectMap.put(volume, currentPool);
        > } else {
        >      throw new CloudRuntimeException("Currently, a volume on managed
        > storage can only be 'migrated' to itself.");
        > }
    The code above is invoked if the user tries to migrate a volume that’s on managed storage
to another storage pool. At present, such volumes can be migrated when a VM is migrated from
one compute cluster to another, but those volumes have to remain on the same managed storage.
    Here’s an example:
    Let’s say VM_1 is in Cluster_1. VM_1 has a root (or data) disk on managed storage. We
try to migrate the VM from Cluster_1 to Cluster_2 and specify a new storage pool for the volume.
This case should fail. To make it work, you need to either 1) not specify a new storage pool
or 2) specify the same storage pool the volume is already in. If the managed storage in question
is zone wide, then it can be used from both Cluster_1 and Cluster_2.
    The new code might call getDefaultMappingOfVolumesAndStoragePoolForMigration (if no storage
pools at all are passed in to the API) or it might call createMappingVolumeAndStoragePoolEnteredByUser.
    If getDefaultMappingOfVolumesAndStoragePoolForMigration is invoked, we silently ignore
the (faulty) input (which is a new storage pool) from the user and keep the volume in its
same managed storage pool (the user may wonder why it wasn’t migrated if they don’t get
an error message back telling them this is not allowed).
    If createMappingVolumeAndStoragePoolEnteredByUser is invoked, we seem to have a bigger
problem (code is below):
    I do not believe you are required to pass in a new storage pool for each and every volume
of the VM. If the VM has, say, three volumes, you may only try to migrate two of the volumes
to new storage pools. This logic seems to assume if you want to migrate one of the VM’s
volumes, then you necessarily want to migrate all of the VM’s volumes. I believe it’s
possible for targetPool to come back null and later throw a NullPointerException. The old
code walks through each volume of the VM and checks if there is a new storage pool specified
for it. If so, do one thing; else, do something else.
        private Map<Volume, StoragePool> createMappingVolumeAndStoragePoolEnteredByUser(VirtualMachineProfile
profile, Host host, Map<Long, Long> volumeToPool) {
            Map<Volume, StoragePool> volumeToPoolObjectMap = new HashMap<Volume,
            for(Long volumeId: volumeToPool.keySet()) {
                VolumeVO volume = _volsDao.findById(volumeId);
                Long poolId = volumeToPool.get(volumeId);
                StoragePoolVO targetPool = _storagePoolDao.findById(poolId);
                StoragePoolVO currentPool = _storagePoolDao.findById(volume.getPoolId());
                if (_poolHostDao.findByPoolHost(targetPool.getId(), host.getId()) == null)
                    throw new CloudRuntimeException(String.format("Cannot migrate the volume
[%s] to the storage pool [%s] while migrating VM [%s] to target host [%s]. The host does not
have access to the storage pool entered.", volume.getUuid(), targetPool.getUuid(), profile.getUuid(),
                if (currentPool.getId() == targetPool.getId()) {
          "The volume [%s] is already allocated in storage
pool [%s].", volume.getUuid(), targetPool.getUuid()));
                volumeToPoolObjectMap.put(volume, targetPool);
            return volumeToPoolObjectMap;
    On 7/16/18, 5:13 AM, "Rafael Weingärtner" <> wrote:
        Ok, I see what happened there with the migration to cluster. When I re-did
        the code I did not have this case. And therefore, in the old code, I was
        not seeing this use case (convoluted code, lack of documentation, and so
        on; we all know the story). I will fix it.
        Regarding the managed storage issue, can you describe the “special
        handling” you need?
        Are you talking about this:
        > if (destPool.getId() == currentPool.getId()) {
        >     volumeToPoolObjectMap.put(volume, currentPool);
        > } else {
        >      throw new CloudRuntimeException("Currently, a volume on managed
        > storage can only be 'migrated' to itself.");
        > }
        That is a simple validation, right? A validation to throw an exception if
        the user tries to migrate the volume to some other storage pool. Is that
        it? If that is the case, the default method
        “getDefaultMappingOfVolumesAndStoragePoolForMigration” already takes care
        of this. Meaning, that it will not try to move the volume to other storage
        On the other hand, we need to add a validation in the
        “createMappingVolumeAndStoragePoolEnteredByUser” method then.
        I will wait for your feedback before starting to code. Thanks for spotting
        this issue.
        On Sun, Jul 15, 2018 at 9:11 PM, Tutkowski, Mike <>
        > Hi Rafael,
        > Thanks for your time on this.
        > Here is an example where the new code deviates from the old code in a
        > critical fashion (code right below is new):
        >     private Map<Volume, StoragePool> getDefaultMappingOfVolumesAndS
        > toragePoolForMigration(VirtualMachineProfile profile, Host targetHost) {
        >         Map<Volume, StoragePool> volumeToPoolObjectMap = new
        > HashMap<Volume, StoragePool>();
        >         List<VolumeVO> allVolumes = _volsDao.findUsableVolumesForInstance(
        > profile.getId());
        >         for (VolumeVO volume : allVolumes) {
        >             StoragePoolVO currentPool = _storagePoolDao.findById(
        > volume.getPoolId());
        >             if (ScopeType.HOST.equals(currentPool.getScope())) {
        >                 createVolumeToStoragePoolMappingIfNeeded(profile,
        > targetHost, volumeToPoolObjectMap, volume, currentPool);
        >             } else {
        >                 volumeToPoolObjectMap.put(volume, currentPool);
        >             }
        >         }
        >         return volumeToPoolObjectMap;
        >     }
        > What happens in the new code (above) is if the user didn’t pass in a
        > storage pool to migrate the virtual disk to (but the VM is being migrated
        > to a new cluster), this code just assigns the virtual disk to its current
        > storage pool (which is not going to be visible to any of the hosts in the
        > new compute cluster).
        > In the old code (I’m looking at 4.11.3 here), you could look around line
        > 2337 for the following code (in the VirtualMachineManagerImpl.
        > getPoolListForVolumesForMigration method):
        >                     // Find a suitable pool for the volume. Call the
        > storage pool allocator to find the list of pools.
        >                     final DiskProfile diskProfile = new
        > DiskProfile(volume, diskOffering, profile.getHypervisorType());
        >                     final DataCenterDeployment plan = new
        > DataCenterDeployment(host.getDataCenterId(), host.getPodId(),
        > host.getClusterId(),
        >                             host.getId(), null, null);
        >                     final List<StoragePool> poolList = new ArrayList<>();
        >                     final ExcludeList avoid = new ExcludeList();
        >                     for (final StoragePoolAllocator allocator :
        > _storagePoolAllocators) {
        >                         final List<StoragePool> poolListFromAllocator =
        > allocator.allocateToPool(diskProfile, profile, plan, avoid,
        > StoragePoolAllocator.RETURN_UPTO_ALL);
        >                         if (poolListFromAllocator != null &&
        > !poolListFromAllocator.isEmpty()) {
        >                             poolList.addAll(poolListFromAllocator);
        >                         }
        >                     }
        > This old code would find an applicable storage pool in the destination
        > cluster (one that can be seen by the hosts in that compute cluster).
        > I think the main error in the new logic is the assumption that a VM can
        > only be migrated to a host in the same computer cluster. For XenServer
        > (perhaps for other hypervisor types?), we support cross-cluster VM
        > migration.
        > The other issue I noticed is that there is no logic in the new code that
        > checks for managed-storage use cases. If you look in the
        > VirtualMachineManagerImpl.getPoolListForVolumesForMigration method in the
        > old code, there is special handling for managed storage. I don’t see this
        > reproduced in the new logic.
        > I sympathize with your point that all tests passed yet this issue was not
        > uncovered. Unfortunately, I suspect we have a fairly low % coverage of
        > automated tests on CloudStack. If we ever did get to a high % of automated
        > test coverage, we might be able to spin up new releases more frequently. As
        > the case stands today, however, there are probably many un-tested use cases
        > when it comes to our automated suite of tests.
        > Thanks again!
        > Mike
        > On 7/15/18, 4:19 PM, "Rafael Weingärtner" <>
        > wrote:
        >     Mike, are you able to pin-point in the old/replaced code the bit that
        > was
        >     handling your use case?  I took the most care not to break anything.
        >     Also, your test case, isn't it in the ACS' integration test suite? In
        >     theory, all test passed when we merged the PR.
        >     I sure can take a look at it. Can you detail your use case? I mean, the
        >     high level execution flow. What API methods you do, what you expected
        > to
        >     happen, and what is happening today.
        >     On Sun, Jul 15, 2018 at 3:25 AM, Tutkowski, Mike <
        >     wrote:
        >     > It looks like this is the problematic PR:
        >     >
        >     >
        >     >
        >     > On 7/15/18, 12:20 AM, "Tutkowski, Mike" <>
        > wrote:
        >     >
        >     >     Hi,
        >     >
        >     >     While running managed-storage regression tests tonight, I
        > noticed a
        >     > problem that is not related to managed storage.
        >     >
        >     >     CLOUDSTACK-10240 is a ticket asking that we allow the migration
        > of a
        >     > virtual disk that’s on local storage to shared storage. In the
        > process of
        >     > enabling this feature, the VirtualMachineManagerImpl.
        >     > getPoolListForVolumesForMigration method was re-written in a way
        > that
        >     > completely breaks at least one use case: Migrating a VM across
        > compute
        >     > clusters (at least supported in XenServer). If, say, a virtual disk
        > resides
        >     > on shared storage in the source compute cluster, we must be able to
        > copy
        >     > this virtual disk to shared storage in the destination compute
        > cluster.
        >     >
        >     >     As the code is currently written, this is no longer possible. It
        > also
        >     > seems that the managed-storage logic has been dropped for some
        > reason in
        >     > the new implementation.
        >     >
        >     >     Rafael – It seems that you worked on this feature. Would you be
        > able
        >     > to look into this and create a PR?
        >     >
        >     >     Thanks,
        >     >     Mike
        >     >
        >     >
        >     >
        >     --
        >     Rafael Weingärtner
        Rafael Weingärtner

View raw message