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 >>
