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 >
