However, perhaps someone can clear this up for me:

With XenServer, we are able to migrate a VM and its volumes from a host using a 
shared SR in one cluster to a host using a shared SR in another cluster even 
though the source host can’t see the target SR.

Is the same thing possible with VMware or does the source host have to be able 
to see the target datastore? If so, does that mean the target datastore has to 
be zone-wide primary storage when using VMware to make this work?

On 3/23/17, 7:47 AM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> wrote:

    This looks a little suspicious to me (in VmwareResource before we call 
VirtualMachineMO.changeDatastore):
    
                    morDsAtTarget = 
HypervisorHostHelper.findDatastoreWithBackwardsCompatibility(tgtHyperHost, 
filerTo.getUuid());
                    morDsAtSource = 
HypervisorHostHelper.findDatastoreWithBackwardsCompatibility(srcHyperHost, 
filerTo.getUuid());
                    if (morDsAtTarget == null) {
                        String msg = "Unable to find the target datastore: " + 
filerTo.getUuid() + " on target host: " + tgtHyperHost.getHyperHostName() + " 
to execute MigrateWithStorageCommand";
                        s_logger.error(msg);
                        throw new Exception(msg);
                    }
    
    We use filerTo.getUuid() when trying to get a pointer to both the target 
and source datastores. Since filerTo.getUuid() has the UUID for the target 
datastore, that works for morDsAtTarget, but morDsAtSource ends up being null.
    
    For some reason, we only check if morDsAtTarget is null (I’m not sure why 
we don’t check if morDsAtSource is null, too).
    
    On 3/23/17, 7:31 AM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> wrote:
    
        Hi,
        
        The CloudStack API that the GUI is invoking is 
migrateVirtualMachineWithVolume (which is expected since I’m asking to migrate 
a VM from a host in one cluster to a host in another cluster).
        
        A MigrateWithStorageCommand is sent to VmwareResource, which eventually 
calls VirtualMachineMO.changeDatastore.
        
            public boolean changeDatastore(VirtualMachineRelocateSpec 
relocateSpec) throws Exception {
                ManagedObjectReference morTask = 
_context.getVimClient().getService().relocateVMTask(_mor, relocateSpec, 
VirtualMachineMovePriority.DEFAULT_PRIORITY);
                boolean result = _context.getVimClient().waitForTask(morTask);
                if (result) {
                    _context.waitForTaskProgressDone(morTask);
                    return true;
                } else {
                    s_logger.error("VMware RelocateVM_Task to change datastore 
failed due to " + TaskMO.getTaskFailureInfo(_context, morTask));
                }
                return false;
            }
        
        The parameter, VirtualMachineRelocateSpec, looks like this:
        
        http://imgur.com/a/vtKcq (datastore-66 is the target datastore)
        
        The following error message is returned:
        
        Required property datastore is missing from data object of type 
VirtualMachineRelocateSpecDiskLocator
        
        while parsing serialized DataObject of type 
vim.vm.RelocateSpec.DiskLocator
        at line 1, column 327
        
        while parsing property "disk" of static type 
ArrayOfVirtualMachineRelocateSpecDiskLocator
        
        while parsing serialized DataObject of type vim.vm.RelocateSpec
        at line 1, column 187
        
        while parsing call information for method RelocateVM_Task
        at line 1, column 110
        
        while parsing SOAP body
        at line 1, column 102
        
        while parsing SOAP envelope
        at line 1, column 38
        
        while parsing HTTP request for method relocate
        on object of type vim.VirtualMachine
        at line 1, column 0
        
        Thoughts?
        
        Thanks!
        Mike
        
        On 3/22/17, 11:50 PM, "Sergey Levitskiy" 
<sergey.levits...@autodesk.com> wrote:
        
            
            Can you trace which API call being used and what parameters were 
specified? migrateVirtualMachineWithVolumeAttempts vs migrateVirtualMachine
            
            
        
        
    
    

Reply via email to