3

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)

dashbord infrastucture

Asanka sanjaya
  • 1,461
  • 3
  • 17
  • 35

1 Answers1

1

I replied to your private email. Will reply here for anybody googling the issue.

This is most likely due to the service offering you are using.

The default Cloudstack service offerings use shared storage. The setup for my GSoC project is all local storage.

You can create a new service offering via the UI and just specified local storage.

Alternatively, open up the SQL database, navigate over to the service_offering_view and modify the use_local_storage column to be 1.

EDIT:

Can you look at the template_view for the template you created based off a volume. Check that the column flag for HVM is set to 0.

Ian Duffy
  • 185
  • 1
  • 8
  • Also be warned there is nested virtualization going on here. Should the CentOS template you're trying to use not have the PV drivers it will not boot. A 32bit one will boot fine without PV drivers. Any 64bit linux distro using kernel 3 or greater will also boot just fine. For testing purposes I usually use debian 7 or the ttylinux_vhd template. – Ian Duffy Sep 07 '14 at 16:39
  • Wouldn't a service offering configured for shared storage also give problems wen creating instances form te tiny linux template? – Miguel Ferreira Sep 08 '14 at 07:36
  • Miguel - The referenced GSoC-2014 project the postee gives sets up cloudstack in a dev-like environment. This environment uses primary storage on the hypervisors themselves (local primary storage). By default all the service offerings (Small instance, Medium Instance, tinyInstance(depending on the version of Cloudstack you have)) that come with cloudstack are configured to use shared storage. Attempting to use a service offering with shared storage where no shared primary storage exists will result in errors. – Ian Duffy Sep 08 '14 at 13:59
  • I understand your point, but if it was possible to create an instance in the first place, doesn't that mean that the service offering was well configured? (I'm assuming that the offering being used to create the second instance from the template is the same as te offering used to create the initial instance from the tiny Linux template) – Miguel Ferreira Sep 08 '14 at 21:02