Re: Issue with VR after upgrade to 4.6.2

Hi Daniel, Please share the MS logs when the VR is going down. I want to check, Is MS bringing down the VR ? or VR is getting rebooted itself. Thanks, Jaqyapal > On 28-Jan-2016, at 5:47 pm, Daniel Mezentsev wrote: > > Hi Remi, > > I just upgraded 4.6.2->4.7.1 The same

Re: Issue with VR after upgrade to 4.6.2

Increased settings to 60. Got VR(s) up and running. Interesting. Hi Daniel, Can you please bump that setting to 15 or 20 and restart mgt server? Then start the router again. Let me know! Regards, Remi Sent from my iPhone On 28 Jan 2016, at 07:00, Daniel Mezentsev wrote:

Re: Issue with VR after upgrade to 4.6.2

Hi Remi, I just upgraded 4.6.2->4.7.1 The same issue, unable to start 2 VRs (out of 8 total). VR actually is started, running for 5-7 minutes, then shuting down. One thing that i noticed in the log: arping -c 1 -I eth0 -A -U -s 10.1.12.1 None What is "None" here ? Please let me know what

Re: Issue with VR after upgrade to 4.6.2

Hi Remi, Setup is the following Cloudstack 4.7.1 One cluster of XenServers (6.2) - 4 hosts Advanced network That 2 routers i have problems with are just DNS and DHCP providers, they are not actibe as default gateway for VMs, there are ~10-12 VMs. router.aggregation.command.each.timeout=3 Hi

Re: Issue with VR after upgrade to 4.6.2

Hi Daniel, Can you please bump that setting to 15 or 20 and restart mgt server? Then start the router again. Let me know! Regards, Remi Sent from my iPhone > On 28 Jan 2016, at 07:00, Daniel Mezentsev wrote: > > Hi Remi, > > Setup is the following > Cloudstack 4.7.1 >

Re: Issue with VR after upgrade to 4.6.2

Jaqyapal, Can you please gimme heads up what is MS ? setting router.aggregation.command.each.timeout=60 solved issue. Hi Daniel, Please share the MS logs when the VR is going down. I want to check,  Is MS bringing down the VR ?  or VR is getting rebooted itself. Thanks, Jaqyapal On

Re: Issue with VR after upgrade to 4.6.2

This means that (at least) one of the commands that are sent takes a much longer time than expected. At least it works now. Jayapal refers to the management server logs. The reason might be in there, or else in the cloud.log on the router. Regards, Remi Sent from my iPhone > On 28 Jan

Re: Issue with VR after upgrade to 4.6.2

Hi Daniel, At what value is router.aggregation.command.each.timeout global setting? Can you tell a bit about your setup, what the router does (config) as in how many VMs, tiers, public IPs etc. Regards, Remi Sent from my iPhone > On 28 Jan 2016, at 05:18, Daniel Mezentsev

Re: Issue with VR after upgrade to 4.6.2

No, just the same template so it's just a matter of upgrading package. Will ping you when the release is ready. Regards, Remi Sent from my iPhone > On 25 Jan 2016, at 21:41, Daniel Mezentsev wrote: > > Hi Remi, > > Absolutely. I don't see any issue to do upgrade to 4.7.1.

Re: Issue with VR after upgrade to 4.6.2

in my configuration VR is acting as DHCP/DNS server, so it's not passing any traffic, so i can exclude public IP addresses. Definetely there is one of the VR script is acting badly.   If I disassociated 10 public IPs and keep 10 public IPs (but keep 20 vms associated with the network), the

Re: Issue with VR after upgrade to 4.6.2

Hi Daniel, Is upgrading to 4.7.1 (once released tomorrow) an option? It has many improvements over 4.6.x and I'm quite sure it fixes the problem you experience now. Regards, Remi Sent from my iPhone > On 25 Jan 2016, at 16:29, Daniel Mezentsev wrote: > > in my

Re: Issue with VR after upgrade to 4.6.2

Hi Remi, Absolutely. I don't see any issue to do upgrade to 4.7.1. Will it be with new templates for system VMs ? Hi Daniel, Is upgrading to 4.7.1 (once released tomorrow) an option? It has many improvements over 4.6.x and I'm quite sure it fixes the problem you experience now. Regards,

Re: Issue with VR after upgrade to 4.6.2

Hello Remi, I've tested with router.aggregation.command.each.timeout global set to 20 without success: same issue (kill in around 5-7 min after the restart command) and with 3600 sec : same issue (kill) (on 4.7.1 RC fresh install) Milamber On 24/01/2016 06:57, Remi Bergsma wrote: Hi, We

Re: Issue with VR after upgrade to 4.6.2

If I disassociated 10 public IPs and keep 10 public IPs (but keep 20 vms associated with the network), the network (virtual router) restart with clean up successfully (around in 3 min). I thinks that is a timeout problem (or VR scripts performance)... but which timeout parameter? On

Re: Issue with VR after upgrade to 4.6.2

Please note, my installation type is Advanced network without security groups (vlan isolation). On 24/01/2016 06:57, Remi Bergsma wrote: Hi, We have seen this issue sometimes in the VRs from 4.6 and on. There have been several improvements in the code in 4.7. Also, setting

Issue with VR after upgrade to 4.6.2

Hi All, I've got some issue after i did cloudstack upgrade 4.5 -> 4.6.2. Environment has 8 VR, 6 were upgraded and restarted successfully, 2 of them stuck. I removed them - the same result, i can't boot them, restarted network with clean-up - no luck. VR actually is starting, i can ssh to it,

Re: Issue with VR after upgrade to 4.6.2

Hello, I've have a similiar issue without solution (but not with an upgrade from 4.5), please see https://issues.apache.org/jira/browse/CLOUDSTACK-9255 Milamber On 24/01/2016 03:32, Daniel Mezentsev wrote: Hi All, I've got some issue after i did cloudstack upgrade 4.5 -> 4.6.2.

Re: Issue with VR after upgrade to 4.6.2

Hi, We have seen this issue sometimes in the VRs from 4.6 and on. There have been several improvements in the code in 4.7. Also, setting router.aggregation.command.each.timeout global setting to 15 or 20 also may help (restart mgt server after change). @Milamber can you test this setting with

Re: Issue with VR after upgrade to 4.6.2

Hi, Seems like you have completely different environment, mine is XenServer + SAN (FC) storage + centos as VMs, but with the same simptoms. Definetely need some input from dev guys. I did research through internet, there are several issues with the same description, but no solution. I'd mark is