[jira] [Commented] (CLOUDSTACK-357) ISOs can be deleted while still attached to a running VM, and they subsequently cannot be detached from a running VM

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

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

ASF subversion and git services commented on CLOUDSTACK-357:
------------------------------------------------------------

Commit 4d573ddd1bcd4ab27edfb91791a830308236521b in branch refs/heads/master from [~deeptid]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;h=4d573dd ]

CLOUDSTACK-357 ISOs can be deleted while still attached to a running VM, and they subsequently cannot be detached from a running VM

I made the changes to make sure that:
1. ISO will be deleted from the UI, but it is not deleted from the secondary storage as long as it is attached to a VM.
2. The storage cleanup thread will check whether the iso is attached to any vm, if not, it removes the ISO from the secondary storage.
3. Detach operation is now working which was failing before for the vms having attached iso(deleted).

Updated the patch for template sync during MS restart.

Manually tested the following:
setup: upload ISO1 and ISO 2
Attach ISO1 to VM1 and VM2
Attach ISO2 to VM3
set storage.cleanup.interval to 300

test cases:
1. delete ISO1 from UI, gets deleted
2. In VM Details of VM1 and VM2, can see detach ISO option
3. ISO1 exists in secondary storage
4. detach ISO1 from VM1, successful
5. ISO1 still exists in secondary storage.
6. Restart MS, template sync will not delete ISO1.
7. Detach ISO1 from VM2, successfull detached.
8. Wait for storage cleanup thread to execute, ISO1 gets deleted from Secondary storage.
9. Detach ISO2 from VM3
10.ISO2 exists in secondary storage, Delete ISO2 form UI, get deleted from secondary storage.

                
> ISOs can be deleted while still attached to a running VM, and they subsequently cannot be detached from a running VM
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-357
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-357
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: ISO
>    Affects Versions: pre-4.0.0
>            Reporter: deepti dohare
>            Assignee: deepti dohare
>            Priority: Minor
>             Fix For: 4.1.0
>
>
> If an ISO is attached to a running VM, and you delete that ISO via CloudStack, the ISO file is deleted from secondary storage. However, it is left attached to the running VM, and it cannot be detached while the VM is running. The exception given in the log is pasted below (full snippet attached). It appears that CloudStack is not even trying to detach it (no tasks show up on vSphere). 
> Shutting down the VM and detaching the ISO works fine, but this is an inconvenience at the least and should be handled better. For example, ISO deletion could fail if it is attached to any VM, ISOs could be automatically detached from VMs before being deleted, or deleted ISOs could be detachable from running VMs. 
> 2012-08-24 08:53:09,785 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-29:job-98) Executing com.cloud.api.commands.DetachIsoCmd for job-98 
> 2012-08-24 08:53:09,801 WARN [cloud.storage.StorageManagerImpl] (Job-Executor-29:job-98) Unable to find secondary storage in zone id=1 
> 2012-08-24 08:53:09,801 WARN [cloud.vm.UserVmManagerImpl] (Job-Executor-29:job-98) Couldn't get absolute iso path 
> 2012-08-24 08:53:09,808 ERROR [cloud.api.ApiDispatcher] (Job-Executor-29:job-98) Exception while executing DetachIsoCmd: 
> com.cloud.utils.exception.CloudRuntimeException: Failed to detach iso 
>         at com.cloud.template.TemplateManagerImpl.detachIso(TemplateManagerImpl.java:1109) 
>         at com.cloud.event.ActionEventCallback.intercept(ActionEventCallback.java:32) 
>         at com.cloud.api.commands.DetachIsoCmd.execute(DetachIsoCmd.java:82) 
>         at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:134) 
>         at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:427) 
>         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.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) 
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) 
>         at java.lang.Thread.run(Thread.java:679) 
> 2012-08-24 08:53:09,809 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-29:job-98) Complete async job-98, jobStatus: 2, resultCode: 530, result: com.cloud.api.response.ExceptionResponse@3cb12e2b 

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