Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Date: Mon, 25 Feb 2013 12:04:12 +0000 (UTC)
From: "deepti dohare (JIRA)" <jira@apache.org>
To: cloudstack-dev@incubator.apache.org
Message-ID: <JIRA.12611972.1350367721267.332721.1361793852894@arcas>
In-Reply-To: <JIRA.12611972.1350367721267@arcas>
References: <JIRA.12611972.1350367721267@arcas>
Subject: [jira] [Resolved] (CLOUDSTACK-357) ISOs can be deleted while still
 attached to a running VM, and they subsequently cannot be detached from a
 running VM
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CLOUDSTACK-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

deepti dohare resolved CLOUDSTACK-357.
--------------------------------------

    Resolution: Fixed
    
> 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