cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ricardo Jose Olvera Flores (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-2647) VM stucks in expunge state even the interval is completed
Date Thu, 06 Nov 2014 17:05:34 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-2647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14200466#comment-14200466
] 

Ricardo Jose Olvera Flores commented on CLOUDSTACK-2647:
--------------------------------------------------------

I have this behaviour with:
Centos 6.5
cloudstack-manager 4.4.1

> VM stucks in expunge state even the interval is completed
> ---------------------------------------------------------
>
>                 Key: CLOUDSTACK-2647
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2647
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Volumes
>    Affects Versions: 4.2.0
>            Reporter: Jayapal Reddy
>
> 1. Create a VM
> 2. Change the expunge delay, interval in global settings to 30.
> 3. Destroy the VM.
> 4. VM staying in destroy state .
> 5. Observed the following exception 
> INFO  [cloud.vm.UserVmManagerImpl] (UserVm-Scavenger-1:) Found 1 vms to expunge.
> WARN  [cloud.vm.UserVmManagerImpl] (UserVm-Scavenger-1:) Unable to expunge VM[User|v1]
> com.cloud.utils.exception.CloudRuntimeException: Failed to update state:com.cloud.utils.exception.CloudRuntimeException:
Failed to transit volume: 4, due to: com.cloud.utils.fsm.NoTransitionException: Unable to
transition to a new state from Expunging via DestroyRequested
> 	at org.apache.cloudstack.storage.volume.VolumeObject.processEvent(VolumeObject.java:198)
> 	at org.apache.cloudstack.storage.volume.VolumeServiceImpl.destroyVolume(VolumeServiceImpl.java:419)
> 	at com.cloud.storage.VolumeManagerImpl.cleanupVolumes(VolumeManagerImpl.java:1995)
> 	at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> 	at com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:457)
> 	at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1413)
> 	at com.cloud.vm.UserVmManagerImpl$ExpungeTask.run(UserVmManagerImpl.java:1582)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
> 	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> 	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> 	at java.lang.Thread.run(Thread.java:680)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message