cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Levitskiy <Sergey.Levits...@autodesk.com>
Subject Re: Cannot migrate VMware VM with root disk to host in different cluster (CloudStack 4.10)
Date Thu, 23 Mar 2017 21:50:39 GMT
It shouldn’t as long the destination host has access to the destination datastore.

On 3/23/17, 1:34 PM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:

    So, in my case, both the source and target datastores are cluster-scoped primary storage
in CloudStack (not zone wide). Would that matter? For XenServer, that cluster-scoped configuration
(but using storage repositories, of course) works.
    
    On 3/23/17, 2:31 PM, "Sergey Levitskiy" <Sergey.Levitskiy@autodesk.com> wrote:
    
        It looks like a bug. For vmware, moving root volume with migrateVolume with livemigrate=true
for zone-wide PS works just fine for us. In the background, it uses StoragevMotion. From another
angle MigrateVirtualMachine works also perfectly fine. I know for a fact that vmware supports
moving from host to host and storage to storage at the same time so it seems to be a bug in
migrateVirtualMachineWithVolume implementation. vSphere standard license is enough for both
regular and storage vMotion.
        
        On 3/23/17, 1:21 PM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
        
            Thanks, Simon
            
            I wonder if we support that in CloudStack.
            
            On 3/23/17, 2:18 PM, "Simon Weller" <sweller@ena.com> wrote:
            
                Mike,
                
                
                It is possible to do this on vcenter, but it requires a special license I
believe.
                
                
                Here's the info on it :
                
                https://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsphere.vcenterhost.doc/GUID-A16BA123-403C-4D13-A581-DC4062E11165.html
                
                https://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsphere.vcenterhost.doc/GUID-561681D9-6511-44DF-B169-F20E6CA94944.html
                
                
                - Si
                ________________________________
                From: Tutkowski, Mike <Mike.Tutkowski@netapp.com>
                Sent: Thursday, March 23, 2017 3:09 PM
                To: dev@cloudstack.apache.org
                Subject: Re: Cannot migrate VMware VM with root disk to host in different
cluster (CloudStack 4.10)
                
                This is interesting:
                
                If I shut the VM down and then migrate its root disk to storage in the other
cluster, then start up the VM, the VM gets started up correctly (running on the new host using
the other datastore).
                
                Perhaps you simply cannot live migrate a VM and its storage from one cluster
to another with VMware? This works for XenServer and I probably just assumed it would work
in VMware, but maybe it doesn’t?
                
                The reason I’m asking now is because I’m investigating the support of
cross-cluster migration of a VM that uses managed storage. This works for XenServer as of
4.9 and I was looking to implement similar functionality for VMware.
                
                On 3/23/17, 2:01 PM, "Tutkowski, Mike" <Mike.Tutkowski@netapp.com> wrote:
                
                    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.Tutkowski@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.Tutkowski@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.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