Mike Tutkowski created CLOUDSTACK-10100:
-------------------------------------------
Summary: migrateVirtualMachineWithVolume API command fails for
questionable reason
Key: CLOUDSTACK-10100
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10100
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.11.0.0
Environment: XenServer
Reporter: Mike Tutkowski
Fix For: 4.11.0.0
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
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
