Also, in case it matters, both datastores are iSCSI based.
> On Mar 23, 2017, at 11:52 AM, Tutkowski, Mike <mike.tutkow...@netapp.com>
> wrote:
>
> My version is 5.5 in both clusters.
>
>> On Mar 23, 2017, at 9:48 AM, Sateesh Chodapuneedi
>> <sateesh.chodapune...@accelerite.com> wrote:
>>
>>
>>>> On 23/03/17, 7:21 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> wrote:
>>
>>>> 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?
>> Yes, Mike. But that’s the case with versions less than 5.1 only. In vSphere
>> 5.1 and later, vMotion does not require environments with shared storage.
>> This is useful for performing cross-cluster migrations, when the target
>> cluster machines might not have access to the source cluster's storage.
>> BTW, what is the version of ESXi hosts in this setup?
>>
>> Regards,
>> Sateesh,
>> CloudStack development,
>> Accelerite, CA-95054
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> DISCLAIMER
>> ==========
>> This e-mail may contain privileged and confidential information which is the
>> property of Accelerite, a Persistent Systems business. It is intended only
>> for the use of the individual or entity to which it is addressed. If you are
>> not the intended recipient, you are not authorized to read, retain, copy,
>> print, distribute or use this message. If you have received this
>> communication in error, please notify the sender and delete all copies of
>> this message. Accelerite, a Persistent Systems business does not accept any
>> liability for virus infected mails.
