[
https://issues.apache.org/jira/browse/CLOUDSTACK-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807716#comment-13807716
]
Likitha Shetty commented on CLOUDSTACK-4985:
--------------------------------------------
Branch 4.2 - 375a59d2f73e23194e1dae5b9ee11ae111a28027
> NPE while deleting old root volumes of a restored VM during storage garbage
> collection
> --------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-4985
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4985
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
> Affects Versions: 4.2.0
> Reporter: Likitha Shetty
> Assignee: Likitha Shetty
> Fix For: 4.2.1
>
>
> When VM is restored using restoreVirtualMachine API, old root volume of the
> VM is marked as destroyed, a new volume is created and made the root volume
> of the VM .
> During the next run of storage garbage collector it tries to expunge the old
> root volume which has been marked as destroyed. But In case of VMware, since
> the VMDK files of the new root volume have replaced the VMDK files of the old
> root volume we see the below error,
> 2013-10-29 09:43:53,479 ERROR [storage.resource.VmwareStorageProcessor]
> (DirectAgent-21:10.102.192.12) delete volume failed due to Exception:
> java.lang.RuntimeException
> Message: Cannot delete file [de9821955e1f3e009b3f2a4529d7439c]
> i-2-20-VM/ROOT-20-flat.vmdk
> java.lang.RuntimeException: Cannot delete file
> [de9821955e1f3e009b3f2a4529d7439c] i-2-20-VM/ROOT-20-flat.vmdk
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:411)
> at
> com.cloud.hypervisor.vmware.mo.DatastoreMO.deleteFile(DatastoreMO.java:175)
> at
> com.cloud.storage.resource.VmwareStorageLayoutHelper.deleteVolumeVmdkFiles(VmwareStorageLayoutHelper.java:276)
> at
> com.cloud.storage.resource.VmwareStorageProcessor.deleteVolume(VmwareStorageProcessor.java:1548)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:114)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> Hence in case of VMware, once the state of the old root volume has been
> updated to destroyed force expunge it from primary storage to avoid the
> garbage collector from trying to delete the new root volume.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
