Re: [VOTE] Apache CloudStack 4.11.1.0 LTS [RC2]

+1 (binding) This is what I did for RC1: I created a new cloud using commit 5f48487dc62fd1decaabc4ab2a10f549d6c82400 (RC1). I ran the automated regression tests for managed storage. All tests passed. This is what I did for RC2: I looked at the Git changelog and didn’t see anything that

Re: SSVM's not starting, timeout for libvirt python script in agent.log

Hi James, I looked at the value and it's already on 50GB. I looked a little more and it seems like after restarting the cloudstack-management service I could no longer reach the console or storage system vm looking at the host, now the cloud0 interface is gone. I am using OVS, but according

Re: SSVM's not starting, timeout for libvirt python script in agent.log

Hi Christoffer, Did you try setting the max.template.iso.size to a higher value (e.g. 50GB)? I think the default is set pretty low. Best, James On Tue, Jun 12, 2018 at 11:10 AM, Christoffer Pedersen wrote: > Just want to update that I still get the ISO error: > > 2018-06-12 17:09:42,194 INFO

Re: [VOTE] Apache CloudStack 4.11.1.0 LTS [RC2]

- release checksums all check out. - I installed an all-KVM 4.9.3.1 with a redundant VPC and two nets with VMs. I upgraded to 4.11.1. The only glitch was that the documentation says to register new system VMs as 'systemvm-kvm-4.11'. This should be 'systemvm-kvm-4.11.1'. The nets kept running and

Re: SSVM's not starting, timeout for libvirt python script in agent.log

Just want to update that I still get the ISO error: 2018-06-12 17:09:42,194 INFO [c.c.t.HypervisorTemplateAdapter] (qtp1096283470-12:ctx-962ec49c ctx-2c82c0e2) (logid:0c7df1d7) Image store doesn't have enough capacity. Skip downloading template to this image store 1 Thanks! On Tue, Jun 12,

Re: SSVM's not starting, timeout for libvirt python script in agent.log

Hi Dag, Yes, I altered the IP addresses as I do not fancy throwing them out on the public net. If you think they have value to the troubleshooting, I can send you the original logdata directly. I configured the networking with OVS and as follows: cloudbr0 - MGMT0 (management interface,

Re: SSVM's not starting, timeout for libvirt python script in agent.log

Chris, Going off in a slightly different direction to previous answers. I suspect your problem is with networking - how have you configured this? When you say you can ping the SSVM on the private interface which IP address do you use and where do you successfully ping from?

RE: SSVM's not starting, timeout for libvirt python script in agent.log

Hi Ivan, Are you talking about this global parameters : router.aggregation.command.each.timeout Best regards, Nicolas Bouige DIMSI cloud.dimsi.fr 4, avenue Laurent Cely Tour d’Asnière – 92600 Asnière sur Seine T/ +33 (0)6 28 98 53 40

Re: SSVM's not starting, timeout for libvirt python script in agent.log

Increasing command timeouts in global parameters can work here. At least I met similar behaviour with VR. вт, 12 июн. 2018 г., 14:39 Christoffer Pedersen : > Hi Nicolas, > > I did a apt show qemu and it gave me this version: > > Version: 1:2.5+dfsg-5ubuntu10.29 > > So I guess tha would be

Re: SSVM's not starting, timeout for libvirt python script in agent.log

Hi Nicolas, I did a apt show qemu and it gave me this version: Version: 1:2.5+dfsg-5ubuntu10.29 So I guess tha would be version 2.5? On Tue, Jun 12, 2018 at 1:04 PM, Nicolas Bouige wrote: > Hello Christoffer, > > > Could you tell us wich qemu version are you using ? > > Nicolas Bouige >

RE: SSVM's not starting, timeout for libvirt python script in agent.log

Hello Christoffer, Could you tell us wich qemu version are you using ? Nicolas Bouige DIMSI cloud.dimsi.fr 4, avenue Laurent Cely Tour d’Asnière – 92600 Asnière sur Seine T/ +33 (0)6 28 98 53 40 De : Christoffer Pedersen Envoyé :

SSVM's not starting, timeout for libvirt python script in agent.log

Hi all, I have an issue regarding the system VMs. After deploying an advanced zone, the system VMs are trying to be created but gets stuck in a "Starting" state, however the Agent state is "Up". I have these logs in the agent.log (sorry for the formatting) 2018-06-12 12:22:06,354 WARN