Hi! This weekend, I;ve learned that (running xenserver 6.5sp1) the systemvmtemplate needs to be exactly "Debian 7 64bit" and *not* "(or the highest Debian release number available in the dropdown)". If using a higher OS, the VM boots but is unable to setup any networking which renders the systemvm quite useless.
After some debugging (and re-spawning multiple hundreds of secondary storage vms) and fixing that issue, I'm now gotting that problem: 2018-07-09 00:00:16,440 INFO [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-108:ctx-eab36b57 job-16295/job-17398 ctx-a161f2a3) (logid:85ed43 b3) Insufficient capacity com.cloud.exception.InsufficientAddressCapacityException: Unable to get a storage network ip addressScope=interface com.cloud.dc.Pod; id=1 at com.cloud.network.guru.StorageNetworkGuru.reserve(StorageNetworkGuru.java:130) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1594) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1565) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1111) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4930) at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5093) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:581) 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:529) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) in fact, there's not one single secondary storage vm running or barely existing, and I can't find the obviously occupied ips of the storage network in the db. could someone please shed some light, where that ip occupation is stored? I'm quite sure that I can clean that up. Thanks in advance! Mit freundlichen Grüßen, Stephan Seitz -- Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 405051-44 Fax: 030 / 405051-19 Amtsgericht Berlin-Charlottenburg - HRB 93818 B Geschäftsführer: Peer Heinlein - Sitz: Berlin
signature.asc
Description: This is a digitally signed message part
