Another piece of info:
I tried this same VM + storage migration using NFS for both datastores instead
of iSCSI for both datastores and it failed with the same error message:
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 326
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
On 3/23/17, 12:33 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> wrote:
Slight typo:
Both ESXi hosts are version 5.5 and both clusters are within the same
VMware datastore.
Should be (datastore changed to datacenter):
Both ESXi hosts are version 5.5 and both clusters are within the same
VMware datacenter.
On 3/23/17, 12:31 PM, "Tutkowski, Mike" <mike.tutkow...@netapp.com> wrote:
A little update here:
In the debugger, I made sure we asked for the correct source datastore
(I edited the UUID we were using for the source datastore).
When VirtualMachineMO.changeDatastore is later invoked having the
proper source and target datastores, I now see this error message:
Virtual disk 'Hard disk 1' is not accessible on the host: Unable to
access file [SIOC-1]
Both ESXi hosts are version 5.5 and both clusters are within the same
VMware datastore.
The source datastore and the target datastore are both using iSCSI.
On 3/23/17, 11:53 AM, "Tutkowski, Mike" <mike.tutkow...@netapp.com>
wrote:
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.
