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.
