cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Bergsma <RBerg...@schubergphilis.com>
Subject Re: AW: AW: AW: AW: upgrading 4.5.2 -> 4.6.0 virtualrouter upgrade timeout
Date Thu, 28 Jan 2016 17:27:42 GMT
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.emrich@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:RBergsma@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.emrich@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:RBergsma@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.emrich@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
>>>
Mime
View raw message