cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8648) "Unable to get storage implementation" when copying template from NFS to S3
Date Sun, 26 Jul 2015 14:42:04 GMT

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

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

Commit 9dbc99c6083ac833045713403f794bf3506065b1 in cloudstack's branch refs/heads/master from
[~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9dbc99c ]

CLOUDSTACK-8648: Pass the proper storage layer when configuring

Signed-off-by: Pierre-Luc Dion <pdion891@apache.org>


> "Unable to get storage implementation" when copying template from NFS to S3
> ---------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8648
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8648
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Secondary Storage
>    Affects Versions: Future, 4.5.2
>            Reporter: Wido den Hollander
>              Labels: qcow2, s3, secondary_storage
>             Fix For: Future
>
>
> In the SSVM this can be observed:
> 2015-07-17 12:12:56,675 WARN  [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-11:null)
Failed to get virtual size, returning file size instead:
> javax.naming.ConfigurationException: Unable to get storage implementation
> 	at com.cloud.storage.template.QCOW2Processor.configure(QCOW2Processor.java:95)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getVirtualSize(NfsSecondaryStorageResource.java:828)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copyFromNfsToS3(NfsSecondaryStorageResource.java:886)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copyFromNfsToImage(NfsSecondaryStorageResource.java:618)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:645)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:233)
> 	at com.cloud.agent.Agent.processRequest(Agent.java:503)
> 	at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
> 	at com.cloud.utils.nio.Task.run(Task.java:84)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:745)
> The problem is this:
> processor.configure("template processor", new HashMap<String, Object>());
> return processor.getVirtualSize(file);
> It confitures the processor with a empty HashMap, but the check in the processor is:
> public boolean configure(String name, Map<String, Object> params) throws ConfigurationException
{
>     _storage = (StorageLayer)params.get(StorageLayer.InstanceConfigKey);
>     if (_storage == null) {
>         throw new ConfigurationException("Unable to get storage implementation");
>     }
> Since the HashMap is empty null is returned and this exception is thrown.
> No need to configure the Processor as far as I can see.



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

Mime
View raw message