cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tutkowski, Mike" <Mike.Tutkow...@netapp.com>
Subject Re: Cannot migrate VMware VM with root disk to host in different cluster (CloudStack 4.10)
Date Thu, 23 Mar 2017 18:31:42 GMT
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.Tutkowski@netapp.com> wrote:

    Also, in case it matters, both datastores are iSCSI based.
    
    > On Mar 23, 2017, at 11:52 AM, Tutkowski, Mike <Mike.Tutkowski@netapp.com> wrote:
    > 
    > My version is 5.5 in both clusters.
    > 
    >> On Mar 23, 2017, at 9:48 AM, Sateesh Chodapuneedi <sateesh.chodapuneedi@accelerite.com>
wrote:
    >> 
    >> 
    >>>> On 23/03/17, 7:21 PM, "Tutkowski, Mike" <Mike.Tutkowski@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.Tutkowski@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.Tutkowski@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.Levitskiy@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.
    

Mime
View raw message