[
https://issues.apache.org/jira/browse/CLOUDSTACK-8597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609692#comment-14609692
]
ASF GitHub Bot commented on CLOUDSTACK-8597:
--------------------------------------------
Github user likitha commented on the pull request:
https://github.com/apache/cloudstack/pull/541#issuecomment-117515627
@wilderrodrigues ,
Background -
1. When CS tries to live migrate a volume, it chooses a host endpoint to
perform the migration by selecting any host that has the storage containing the
volume mounted on it. Now when we attempt to migrate a volume that is on a zone
wide storage, the endpoint could be any host in the zone because in case of
zone wide storage, every host in the zone has the storage mounted on it.
2. During migration, vCenter expects the target datastore/storage pool to
be mounted on the source host because the VM obviously needs to be able to
access the target datastore.
Now in the mentioned issue, say a host that doesn't contain the VM is
chosen as the endpoint. As mentioned above, it could happen because today CS
chooses any host that has the source storage mounted on it. In that case
migration will fail because this host cant see the target datastore.
By picking the host containing the volume's VM as endpoint we ensure that
both the source and target storage pools are visible to the VM irrespective of
the scope of the storage pool.
Previously, similar fixes have been made for other operations like volume
deletion, snapshot creation because in these cases as well the underlying
resource needs the VM of the volume to be visible to the host endpoint.
> Failed to migrate a volume from zone-wide to cluster-wide storage.
> ------------------------------------------------------------------
>
> Key: CLOUDSTACK-8597
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8597
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Reporter: Likitha Shetty
> Assignee: Likitha Shetty
> Fix For: 4.6.0
>
>
> +Steps to reproduce+
> 1. Have 2 clusters with a host and cluster-wide storage each.
> 2. Have a zone-wide storage spanning both clusters.
> 3. Deploy a VM with a datadisk.
> 4. Ensure datadisk is on the zone-wide storage. Attempt to migrate it to the
> cluster-wide storage (cluster that contains the disks's VM).
> 5. Try the above operation repeatedly till a failure is seen.
> Migration may fails with the below -
> {noformat}
> 2015-06-08 14:37:00,079 ERROR [c.c.h.v.r.VmwareResource]
> (DirectAgent-86:ctx-b374c26e 10.102.192.12, job-192/job-193, cmd:
> MigrateVolumeCommand) (logid:ea70ca83) Unable to find the mounted datastore
> with name 23b5a868-b6af-3692-85f5-f1d987b7f3e2 to execute MigrateVolumeCommand
> 2015-06-08 14:37:00,084 ERROR [c.c.h.v.r.VmwareResource]
> (DirectAgent-86:ctx-b374c26e 10.102.192.12, job-192/job-193, cmd:
> MigrateVolumeCommand) (logid:ea70ca83) Catch Exception java.lang.Exception
> due to java.lang.Exception: Unable to find the mounted datastore with name
> 23b5a868-b6af-3692-85f5-f1d987b7f3e2 to execute MigrateVolumeCommand
> java.lang.Exception: Unable to find the mounted datastore with name
> 23b5a868-b6af-3692-85f5-f1d987b7f3e2 to execute MigrateVolumeCommand
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3561)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:414)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:317)
> 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:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
