You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by ha...@apache.org on 2020/11/19 07:14:19 UTC

[cloudstack] branch fixMigrateVMwithVolume_in_VMwareVsphere created (now e9cabd0)

This is an automated email from the ASF dual-hosted git repository.

harikrishna pushed a change to branch fixMigrateVMwithVolume_in_VMwareVsphere
in repository https://gitbox.apache.org/repos/asf/cloudstack.git.


      at e9cabd0  Fix migrateVMwithVolumes API in case of VMware to address the case when only volume is tried to migrate along with VM.

This branch includes the following new commits:

     new e9cabd0  Fix migrateVMwithVolumes API in case of VMware to address the case when only volume is tried to migrate along with VM.

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.



[cloudstack] 01/01: Fix migrateVMwithVolumes API in case of VMware to address the case when only volume is tried to migrate along with VM.

Posted by ha...@apache.org.
This is an automated email from the ASF dual-hosted git repository.

harikrishna pushed a commit to branch fixMigrateVMwithVolume_in_VMwareVsphere
in repository https://gitbox.apache.org/repos/asf/cloudstack.git

commit e9cabd025114ea1cac6ef89e70819e74af99d81e
Author: Harikrishna Patnala <ha...@gmail.com>
AuthorDate: Thu Nov 19 11:21:39 2020 +0530

    Fix migrateVMwithVolumes API in case of VMware to address the case when only volume is tried to migrate along with VM.
    
    Problem:
    When migrateVMwithVolumes API is tried on a VM with two volumes to migrate to a different host and tried to migrate only one volume, Cloudstack migrates both the Volumes but then marks only one of them migrated. This makes volume inaccessible due to inconsitency in path of volume in cloudstack and vsphere
    
    Solution:
    Set the target datastore in relocate spec properly for each volume
---
 .../java/com/cloud/hypervisor/vmware/resource/VmwareResource.java   | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/plugins/hypervisors/vmware/src/main/java/com/cloud/hypervisor/vmware/resource/VmwareResource.java b/plugins/hypervisors/vmware/src/main/java/com/cloud/hypervisor/vmware/resource/VmwareResource.java
index a3da897..56d08a4 100644
--- a/plugins/hypervisors/vmware/src/main/java/com/cloud/hypervisor/vmware/resource/VmwareResource.java
+++ b/plugins/hypervisors/vmware/src/main/java/com/cloud/hypervisor/vmware/resource/VmwareResource.java
@@ -4694,7 +4694,7 @@ public class VmwareResource implements StoragePoolResource, ServerResource, Vmwa
                 }
 
                 diskLocator = new VirtualMachineRelocateSpecDiskLocator();
-                diskLocator.setDatastore(morDsAtSource);
+                diskLocator.setDatastore(morTgtDatastore);
                 Pair<VirtualDisk, String> diskInfo = getVirtualDiskInfo(vmMo, appendFileType(volume.getPath(), VMDK_EXTENSION));
                 String vmdkAbsFile = getAbsoluteVmdkFile(diskInfo.first());
                 if (vmdkAbsFile != null && !vmdkAbsFile.isEmpty()) {
@@ -4717,9 +4717,7 @@ public class VmwareResource implements StoragePoolResource, ServerResource, Vmwa
                     diskLocators.add(diskLocator);
                 }
             }
-            if (srcHyperHost.getHyperHostCluster().equals(tgtHyperHost.getHyperHostCluster())) {
-                relocateSpec.getDisk().addAll(diskLocators);
-            }
+            relocateSpec.getDisk().addAll(diskLocators);
 
             // Prepare network at target before migration
             NicTO[] nics = vmTo.getNics();