>> On 23/03/17, 7:21 PM, "Tutkowski, Mike" <[email protected]> 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" <[email protected]> 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" <[email protected]>
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"
<[email protected]> 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.
