Uploaded image for project: 'CloudStack'
  1. CloudStack
  2. CLOUDSTACK-10100

migrateVirtualMachineWithVolume API command fails for questionable reason

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 4.11.0.0
    • 4.11.0.0
    • Management Server
    • Security Level: Public (Anyone can view this level - this is the default.)
    • None
    • XenServer

    Description

      I have two XenServer clusters, each with its own NFS SR.

      In the one cluster, I have a VM. Its root disk is housed on the one and only NFS SR of that cluster.

      The GUI tells me I can migrate the VM to a host in the other cluster, but that it will require storage migration. I am OK with this and start the migration action.

      The action fails due to this issue:

      https://issues.apache.org/jira/browse/CLOUDSTACK-10099

      I decide instead to run the command from CloudMonkey:

      mtutkowski-LT:cloudstack mtutkowski-LT$ cloudmonkey migrateVirtualMachineWithVolume virtualmachineid=02fc8d09-bcf8-4cbb-b585-f9d0a5fa941e hostid=db5b18b7-efe9-46c2-a6b9-8ef6ee827db8 migrateto[0].volume=7311df6a-9e4a-4b93-931c-935a01a8883e migrateto[0].pool=043d08c2-5a91-33b7-b65f-93a9feb3f118
      Async job 47dec777-03c1-41aa-8d0d-25a9c29f1c0d failed
      Error 530, Failed to migrated vm VM[User|i-2-6-VM] along with its volumes.
      accountid = 8137e311-a407-11e7-ab3d-000c299aca85
      cmd = org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd
      created = 2017-09-28T22:34:53-0600
      jobid = 47dec777-03c1-41aa-8d0d-25a9c29f1c0d
      jobprocstatus = 0
      jobresult:
      errorcode = 530
      errortext = Failed to migrated vm VM[User|i-2-6-VM] along with its volumes.
      jobresultcode = 530
      jobresulttype = object
      jobstatus = 2
      userid = 8137f9ca-a407-11e7-ab3d-000c299aca85

      I receive the following exception in the console of my management server:

      com.cloud.utils.exception.CloudRuntimeException: Can not see storage pool: /export/primary from on host:190e8601-6d21-476a-b7d6-e93e953eaa54
      at com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.getStorageRepository(CitrixResourceBase.java:3223)
      at com.cloud.hypervisor.xenserver.resource.wrapper.xen610.XenServer610MigrateWithStorageReceiveCommandWrapper.execute(XenServer610MigrateWithStorageReceiveCommandWrapper.java:75)
      at com.cloud.hypervisor.xenserver.resource.wrapper.xen610.XenServer610MigrateWithStorageReceiveCommandWrapper.execute(XenServer610MigrateWithStorageReceiveCommandWrapper.java:49)
      at com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
      at com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:1728)
      at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315)
      at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
      at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
      at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
      at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
      at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
      at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      at java.lang.Thread.run(Thread.java:745)

      However, I believe this should work.

      The exception implies that the source host needs to be able to see the destination SR, but I don't think this is actually a XenServer requirement.

      I believe the source host only needs to be able to see the source SR and the destination host only needs to be able to see the destination SR.

      My reason for believing this is because I have support in CloudStack for Storage XenMotion for managed storage and I have seen a successful Storage XenMotion when the source host only sees the source SR and the destination host only sees the destination SR.

      This video demonstrates what I'm referring to about the source host only needing to see the source SR and the destination host only needing to see the destination SR:

      https://www.youtube.com/watch?v=_pbnvQxTAqw&t=1006s&list=PLqOXKM0Bt13DFnQnwUx8ZtJzoyDV0Uuye&index=17

      Attachments

        Activity

          There are no comments yet on this issue.

          People

            Unassigned Unassigned
            mike-tutkowski Mike Tutkowski
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: