Unable to add instances using a template which is created from snapshot

7 septembre 2014 14:25

Unable to add instances using a template which is created from snapshot

Hi all,

I followed this https://github.com/imduffy15/GSoC-2014/ and installed apache cloudstack with basic networking in my local machine, and every thing worked smoothly.

?I can add instances from the built in tiny linux template(cent-os 5.6 64bit) without having any issue.

I got a snapshot of the running instance volume and created a template from it. When I try to add an instance using that template I always get InsufficientServerCapacityException.

According to my dashboard there are enough capacity to add the instance. Any ideas?

console:

?WARN [o.a.c.alerts] (API-Job-Executor-5:ctx-4692c763 job-166 ctx-b141500e) alertType:: 8 // dataCenterId:: 1 // podId:: null // clusterId:: null // message:: Failed to deploy Vm with Id: 29, on Host with Id: null
INFO [o.a.c.a.c.a.v.DeployVMCmdByAdmin] (API-Job-Executor-5:ctx-4692c763 job-166 ctx-b141500e) com.cloud.exception.InsufficientServerCapacityException: Unable to create a deployment for VM[User|i-2-29-VM]Scope=interface com.cloud.dc.DataCenter; id=1
INFO [o.a.c.a.c.a.v.DeployVMCmdByAdmin] (API-Job-Executor-5:ctx-4692c763 job-166 ctx-b141500e) Unable to create a deployment for VM[User|i-2-29-VM]
com.cloud.exception.InsufficientServerCapacityException: Unable to create a deployment for VM[User|i-2-29-VM]Scope=interface com.cloud.dc.DataCenter; id=1
at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:214)
at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:200)
at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3515)
at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3166)
at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3154)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy224.startVirtualMachine(Unknown Source)
at org.apache.cloudstack.api.command.admin.vm.DeployVMCmdByAdmin.execute(DeployVMCmdByAdmin.java:48)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)

asankasanjaya MEMBERS 07 September 2014 - 14:25 PM

2 commentaires

Vous devez vous connecter pour laisser un commentaire.

Previous 2 commentaires

Date Votes

Erik Godin

23 mars 2016 07:30

Maybe I'm missing something but I don't see in the output above why the deployment failed. Maybe if logging was turned up it would be more obvious. Every task that runs has a job name and the easiest way to troubleshoot a failed action is to grep management-server.log for that name, i.e. above your output shows job-166

I've been stomped before by an insufficient capacity error message and it turned out I had the CPU frequency too high. The CPU is 2.665 or something in the database but the web gui rounds it up to 2.67. When I created a new template (I was new to CPP) I keyed in 2.67 since that's what I had observed from the other templates but to my surprise every deployment I tried with that template would fail.