Like I said, it’s already much better in 4.7.1. I start to see packages appearing, for example here: http://cloudstack.apt-get.eu/centos7/4.7/oss/
With 4.7.1 we tested hundreds of rules and that worked fine. Regards, Remi On 28/01/16 17:24, "Martin Emrich" <martin.emr...@empolis.com> wrote: >This was/is 4.7.0. > >With the KVM problem: I suspect that the KVM hosts somehow got wonky, as the >VR has no network connectivity (tried virsh console to it, and had no internet >there). Next I'll try rebooting one. > >Another network (with 48 firewall/portforwarding rules) took ca. 30min, the >first one with 22 rules took 10 minutes, so the time is consumed during >configuration of the rules. > >Ciao > >Martin > >-----Ursprüngliche Nachricht----- >Von: Remi Bergsma [mailto:rberg...@schubergphilis.com] >Gesendet: Donnerstag, 28. Januar 2016 17:20 >An: users@cloudstack.apache.org >Betreff: Re: AW: AW: AW: upgrading 4.5.2 -> 4.6.0 virtualrouter upgrade timeout > >The 4.7.1 packages will be there soon. I’d advise anyone currently on 4.6 to >upgrade to it as it has several speed improvements. > >What version was this Martin? > >Regards, >Remi > > > > >On 28/01/16 15:46, "Martin Emrich" <martin.emr...@empolis.com> wrote: > >>Thanks, that's it. >> >>So (at least) I seem to have two issues: >> >>1. VirtualRouters now fail to start on KVM (at least when there's already a >>VR on the KVM host) , but work on XenServer. >> >>2. VirtualRouters take very long to start since 4.6: The VR I just started >>belongs to a network with some 20 firewall and port forwarding rules, and the >>VR took ca. 10 minutes to configure (eating 100% CPU in the process). Thanks >>to setting the timeout high enough, the network finally came up. >>I took a copy of the VR cloud.log ca. 8 minutes into the process, if anyone >>is interested. >> >>Ciao >> >>Martin >> >>-----Ursprüngliche Nachricht----- >>Von: Remi Bergsma [mailto:rberg...@schubergphilis.com] >>Gesendet: Donnerstag, 28. Januar 2016 14:09 >>An: users@cloudstack.apache.org >>Betreff: Re: AW: AW: upgrading 4.5.2 -> 4.6.0 virtualrouter upgrade timeout >> >>Hi Martin, >> >>4.7.1 has a fix for the overall timeout of 120 seconds. I expect the packages >>will be ready in a day or two. >> >>If XenServer works, try setting system.vm.default.hypervisor to XenServer and >>it will not use another hypervisor. >> >>Regards, >>Remi >> >> >> >>On 28/01/16 13:38, "Martin Emrich" <martin.emr...@empolis.com> wrote: >> >>>Hi! >>> >>>To follow up: >>> >>>- I upgraded to 4.7.0 (there are no 4.7.1 el6 RPMs yet, neither from >>>CloudStack nor from Shapeblue) >>>- The problem still persists >>>- It seems that VRs can be created on XenServer, but not on KVM. I tried >>>forcing new VRs to XenServers only via host tags, but the decision to use >>>KVM is being made before the tags are evaluated, so this leaves no hosts >>>when the decision for KVM is made. >>>- I see this in the KVM host agent.log: >>>2016-01-28 13:29:10,956 WARN [kvm.resource.LibvirtComputingResource] >>>(Script-2:null) (logid:) Interrupting script. >>>2016-01-28 13:29:10,958 WARN [kvm.resource.LibvirtComputingResource] >>>(agentRequest-Handler-4:null) (logid:7d8981d1) Timed out: >>>/usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh vr_cfg.sh >>>169.254.3.252 -c >>>/var/cache/cloud/VR-0193b95c-96ee-4e0d-a527-964960baa49e.cfg . Output is: >>>- router.aggregation.command.each.timeout is set to whopping 600s, but the >>>error appears ca. 1-2 minutes after I click on "restart network" with >>>cleanup=true. >>> >>> >>>Any Ideas? >>> >>>Thanks >>> >>>Martin >>>
