cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8597) Failed to migrate a volume from zone-wide to cluster-wide storage.
Date Wed, 01 Jul 2015 07:50:05 GMT

    [ 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)

Mime
View raw message