VMware Solutions Discussions

VSC 4 Provisioning and Cloning Errors



I am having an issue getting the provisioning and cloning to work with vSphere 5. When I try and provision a new datastore I get the follwoing error:

Could not validate the selected storage controller. It failed with the following error: "Timeout error". If you changed the SSL settings or password you must remove and re-add the storage controller to continue.

Please se attached file.




Based on the error message it seems to be a communication issue (timeout).

Have you double-checked that the vCenter can connect to the filers?

Do you want to use SSL?
How did you configure the filers under Monitor and Host configuration? Did you tick the box for "use SSL"?

Please double check if the option httpd.admin.enable is enabled on the filers.

Once you have double-checked all of above suggestions, it is time to reproduce the error and have a look into the log files.
The log file is located under C:\Program Files\NetApp\Virtual Storage Console\logs\kamino.log (kamino.log = Log for Provisioning and Cloning operations)

At the bottom of the log you should be able to find a more precise error message. Just search for time out or error.
You also could provide the log here and I will help you to have a look through.




Hi Jan,

Thanks for getting back to me. Yes, vCenter can connect to the filers. Yes, I am using ssl but I do not have to. The options httpd.admin.enable as well as httpd.admin.ssl.enable is on. I have attached the log for you perusal to my original post. Please alos not that it is only the provisioning that is not working for some reason.



Hi mornevanr,

Based on the log file it seems that you have added the filer under Monitor and Host Configuration with the filer name / FQDN.

Could you please try to delete the filer from Monitor and Host Configuration and add it again with the IP address?

Can you please confirm that the IP address of the affected filer is: and can is pingable from the vCenter.

Is the IP address a management IP address or an IP address which is dedicated for special traffic like iscsi/nfs etc.?

You said that only provisioning doesn't. Does mount datastore (also a function of Provisioning and Cloning) work?

Have you tried to provision a new datastore on another filer? Does it work?

How many LUNs do you have on the filer?
Based on the log file it seems that the time out happens once VSC triggers the "populateLun" function:

2012-07-09 09:11:07,326 (Thread-113) DEBUG [ControllerUtil] - populateLun (7-mode): start NtapFiler[id=1575086902-0, name=EOH-EC-STR-ProdA, connectIpAddress=]

2012-07-09 09:11:19,144 (494405042@qtp-1947348380-28) DEBUG [ServerServiceImpl] - timeout exception


          at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)

          at java.util.concurrent.FutureTask.get(Unknown Source)

          at com.netapp.kamino.server.ServerServiceImpl.refreshController(ServerServiceImpl.java:483)

          at com.netapp.kamino.server.ServerServiceImpl.refreshController(ServerServiceImpl.java:386)

          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

          at java.lang.reflect.Method.invoke(Unknown Source)

          at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:562)

          at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:188)

          at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:224)

          at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)

          at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)

          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

          at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)

          at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)

          at com.netapp.nvpf.container.vsphere.security.VSphereAuthorizationFilter.doFilter(VSphereAuthorizationFilter.java:80)

          at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)

          at com.netapp.nvpf.container.vsphere.request.VSphereClientRequestContextFilter.doFilterInternal(VSphereClientRequestContextFilter.java:47)

          at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)

          at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)

          at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83)

          at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)

          at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)

          at com.netapp.nvpf.container.util.GWTCacheFilter.doFilter(GWTCacheFilter.java:55)

          at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)

          at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)

          at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)

          at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)

          at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)

          at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)

          at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)

          at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

          at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

          at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)

          at org.mortbay.jetty.Server.handle(Server.java:326)

          at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)

          at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)

          at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)

          at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)

          at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)

          at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)

          at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:680)

          at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

Also, could you please share your ONTAP version?





When I said everything else worked I meant Backup & Recovery, Optimisation etc. I can provision a LUN via the Optimisation and Migration if I use the migrate options and choose to create a new lun. I have about 5 luns split accross the 2 filers. I can ping both the name as well as the ip from the vCenter server. Also not that VSC is installed on the vCenter server, could that maybe cause the conflict? I am running VSC 4.0 and DataOntap 8.0.2P4. That IP is the management IP.



I am having a similar error, where it is trying to use a management IP that will not allow NFS or ISCSI on that VLAN and have a specifiic VLAN for ISCSI and another for NFS.  Is there a way to define the networks other then just fencing them from VSC.  I can get this to work if I only provision NFS luns, and only allow the NFS interface access to VSC, but I need NFS to talk on the NFS VLAN and ISCSI luns on the ISCSI VLAN.