[
https://issues.apache.org/jira/browse/CLOUDSTACK-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk closed CLOUDSTACK-3249.
-----------------------------------------
Couldn't reproduce in the latest build
(a6bf80216466ada185de7e04d3e64be4e25c11a7)
> [Object_Store_Refactor] Unable to deployVm from template when the management
> server was restarted in the middle of Secondary to Primary storage template
> download
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-3249
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3249
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.2.0
> Reporter: Alena Prokharchyk
> Assignee: Min Chen
> Priority: Critical
> Fix For: 4.2.0
>
>
> Steps to reproduce:
> 1) Have 1 cluster, 1 primary storage in cluster.
> 2) Call deployVm command.
> 3) After the command to copy template from secondary to primary storage, was
> sent over to the hypervisor, restart the MS.
> 4) After the MS is restarted, try to deploy new vm from the same template.
> The job gets stuck, and in the MS you see messages like:
> "Multiple threads are trying to copy template to primary storage, current
> thread should just wait"
> The current thread will wait for eternity. The problem is, on the step #3 the
> record was created in template_spool_ref table, and the record stays there in
> Creating state even after the MS restarts. So when new deployVm is called, it
> checks the table, sees the record and thinks that some other thread does the
> download, while that thread was gone with the management server restart.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
