Hi Pierre, Good that it works now, could you create a bug at:
https://issues.apache.org/jira/browse/CLOUDSTACK thanks -Sebastien On Jul 25, 2013, at 7:38 AM, Pierre Benard <[email protected]> wrote: > Hi, > > The problem is solved. > Our primary storage usage was more than 85%. > And, CS primary storage settings were : > pool.storage.allocated.capacity.disablethreshold : 0.85 > pool.storage.capacity.disablethreshold : 0.85 > > Consequence : CloudStacjk didn't create new vm. > But, we don't see any error or specific alert from the interface or in system > log. > It's very to understand the problem in this condition. > > I hope new version of cloudstack can say, "your storage is 85% full, you'll > can't create new vm". > > Thanks for all. > > Pierre > > ----- Mail original ----- >> De: "Pierre Benard" <[email protected]> >> À: [email protected] >> Envoyé: Mercredi 24 Juillet 2013 11:17:40 >> Objet: Re: Cloudstack can't deploy new vm >> >> Hi, >> >> I've restart my virtual router VM and my CloudStack server this >> morning (around 10h30). >> >> After, i've test to create new instance : >> * @10h36 : create new instance --> error, but errors are present in >> the log file on CS server >> * @10h55 : create new instance --> fail, but no errors in the log >> file on CS server >> >> - I've generated the first vm too quickly after the reboot of server >> ? >> - Where is the traces of my second tentative ? >> - I attach the log var/log/cloud/management/management-server.log to >> this mail. >> >> Regards >> >> Pierre >> >> ----- Mail original ----- >>> De: "Pierre Benard" <[email protected]> >>> À: [email protected] >>> Envoyé: Mardi 23 Juillet 2013 18:05:53 >>> Objet: Re: Cloudstack can't deploy new vm >>> >>> Yes it's all. >>> We have no log for 22th. >>> >>> I've activated the debug level log the last week and i've restarted >>> the service after, cf : >>> >>> #sed -i 's/INFO/DEBUG/g' /etc/cloud/management/log4j-cloud.xml >>> #service cloud-management restart >>> >>> Tomorrow, I could probably reboot my cloudstackserver between 9am >>> and >>> 12am (GMT+1 Paris). >>> I'll send you the log after that. >>> >>> Regards, >>> >>> >>> Pierre >>> >>> ----- Mail original ----- >>>> De: "Kirk Jantzer" <[email protected]> >>>> À: "Cloudstack users mailing list" <[email protected]> >>>> Envoyé: Mardi 23 Juillet 2013 17:53:16 >>>> Objet: Re: Cloudstack can't deploy new vm >>>> >>>> That's all that's in your log? >>>> >>>> >>>> On Tue, Jul 23, 2013 at 11:35 AM, Pierre Benard >>>> <[email protected]>wrote: >>>> >>>>> Hi, >>>>> >>>>> The log is really short for today (we've made some creating >>>>> tests >>>>> today): >>>>> >>>>> 2013-07-23 14:55:58,608 ERROR >>>>> [cloud.server.ManagementServerImpl] >>>>> (catalina-exec-10:null) Incorrect format of the template id 460 >>>>> 2013-07-23 14:55:59,858 ERROR >>>>> [cloud.server.ManagementServerImpl] >>>>> (catalina-exec-6:null) Incorrect format of the template id 439 >>>>> >>>>> The precedent log is dated on 21th, and it is short too : >>>>> >>>>> 2013-07-21 15:17:08,664 ERROR [cloud.api.ApiDispatcher] >>>>> (Job-Executor-32:job-10294) Exception while executing >>>>> StopVMCmd: >>>>> com.cloud.utils.exception.CloudRuntimeException: We cannot stop >>>>> VM[User|i-451-2756-VM] when it is in state Starting >>>>> at >>>>> com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1005) >>>>> at >>>>> com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:2776) >>>>> at >>>>> com.cloud.event.ActionEventCallback.intercept(ActionEventCallback.java:32) >>>>> at >>>>> com.cloud.api.commands.StopVMCmd.execute(StopVMCmd.java:114) >>>>> at >>>>> com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:132) >>>>> 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) >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Pierre >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Kirk Jantzer" <[email protected]> >>>>>> À: "Cloudstack users mailing list" >>>>>> <[email protected]> >>>>>> Envoyé: Mardi 23 Juillet 2013 17:21:37 >>>>>> Objet: Re: Cloudstack can't deploy new vm >>>>>> >>>>>> Sorry, saw you're on v3. the correct location is: >>>>>> /var/log/cloud/management/management-server.log >>>>>> >>>>>> >>>>>> On Tue, Jul 23, 2013 at 11:20 AM, Kirk Jantzer >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Please paste the contents >>>>>>> of /var/log/cloudstack/management/management-server.log to >>>>>>> PasteBin >>>>>>> so that >>>>>>> we can analyze that. >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 23, 2013 at 11:10 AM, Pierre Benard >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Thank you for your answer. >>>>>>>> >>>>>>>> Our virtual router vm was used @50% of CPU and the network >>>>>>>> traffic >>>>>>>> it was >>>>>>>> amazing. >>>>>>>> We had some system scripts who send DNS request storm on >>>>>>>> virtual >>>>>>>> router. >>>>>>>> Now, we have corrected this and now the usage of cpu is >>>>>>>> under >>>>>>>> 1% >>>>>>>> and >>>>>>>> network traffic is "normal". >>>>>>>> >>>>>>>> But, this operation don't be resolving our problems of new >>>>>>>> instance >>>>>>>> deployment :-( >>>>>>>> >>>>>>>> Somebody has an other idea ? >>>>>>>> >>>>>>>> Thanks in advance. >>>>>>>> >>>>>>>> Pierre >>>>>>>> >>>>>>>> ----- Mail original ----- >>>>>>>>> De: "ramnivas indani" <[email protected]> >>>>>>>>> À: [email protected] >>>>>>>>> Envoyé: Mardi 23 Juillet 2013 10:27:11 >>>>>>>>> Objet: Re: Cloudstack can't deploy new vm >>>>>>>>> >>>>>>>>> We also face this kind of problem many times but in our >>>>>>>>> case >>>>>>>>> its >>>>>>>>> because of >>>>>>>>> router or storage instance are disconnected or down >>>>>>>>> under >>>>>>>>> vmware, i >>>>>>>>> will >>>>>>>>> suggest you to check their connectivity once not only >>>>>>>>> from >>>>>>>>> cloudstack >>>>>>>>> but >>>>>>>>> also from backend. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jul 23, 2013 at 1:50 PM, Pierre Benard >>>>>>>>> <[email protected]>wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We have a problem with our CloudStack. >>>>>>>>>> We can't deploying new instance. When we try to deploy >>>>>>>>>> new >>>>>>>>>> vm >>>>>>>>>> we >>>>>>>>>> have a >>>>>>>>>> short error message on the CloudStack interface : >>>>>>>>>> "Unable >>>>>>>>>> to >>>>>>>>>> create >>>>>>>>>> a >>>>>>>>>> deployment for VM[User|i-3-2764-VM]" . We have the >>>>>>>>>> same >>>>>>>>>> error >>>>>>>>>> when >>>>>>>>>> we >>>>>>>>>> deploy new instance from iso or template. >>>>>>>>>> In the event page on CS, we have : >>>>>>>>>> >>>>>>>>>> VM.CREATE Error while starting Vm. Vm Id: 2764 >>>>>>>>>> [email protected] 22 Jul 2013 13:15:47 >>>>>>>>>> VM.CREATE Starting job for starting Vm. Vm Id: >>>>>>>>>> 2764 >>>>>>>>>> [email protected] 22 Jul 2013 13:15:47 >>>>>>>>>> VM.CREATE Scheduled async job for starting Vm. >>>>>>>>>> Vm >>>>>>>>>> Id: >>>>>>>>>> 2764 >>>>>>>>>> [email protected] 22 Jul 2013 13:15:46 >>>>>>>>>> VM.CREATE Successfully created entity for >>>>>>>>>> deploying >>>>>>>>>> Vm. >>>>>>>>>> Vm >>>>>>>>>> Id: 2764 >>>>>>>>>> [email protected] 22 Jul 2013 13:15:46 >>>>>>>>>> >>>>>>>>>> Isn't really verbose ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> All the other instance are continuous to running >>>>>>>>>> correctly, we >>>>>>>>>> can >>>>>>>>>> stop/start it. >>>>>>>>>> There is no significant error in the log files of >>>>>>>>>> CloudStack >>>>>>>>>> server >>>>>>>>>> and on >>>>>>>>>> each we sufficient resources to deploy many instances. >>>>>>>>>> The SSVM and primary storage are available. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Our CloudStack environment : >>>>>>>>>> * CloudStack v3 >>>>>>>>>> * 1 pod of 4 clusters KVM, each cluster has 4 KVM >>>>>>>>>> hypervisor >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please Suggest. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Pierre Bénard >>>>>>>>>> System engineer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Inria Rennes - Bretagne Atlantique >>>>>>>>>> >>>>>>>>>> Campus universitaire de Beaulieu >>>>>>>>>> 35042 Rennes Cedex >>>>>>>>>> Tél. +33 2 99 84 71 00 >>>>>>>>>> Fax +33 2 99 84 71 71 >>>>>>>>>> www.inria.fr >>>>>>>>>> >>>>>>>>>> Suivez‐nous sur : >>>>>>>>>> Twitter twitter.com/inria >>>>>>>>>> YouTube youtube.com/inriachannel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> Kirk Jantzer >>>>>>> c: (678) 561-5475 >>>>>>> http://about.met/kirkjantzer >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> >>>>>> Kirk Jantzer >>>>>> c: (678) 561-5475 >>>>>> http://about.met/kirkjantzer >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Kirk Jantzer >>>> c: (678) 561-5475 >>>> http://about.met/kirkjantzer >>>> >>>
