Indeed, thats what I had in mind. Keep trying to ssh with a suitable timeout.
Thanks!
Regards,
Girish
On 30-Sep-2013, at 2:40 PM, Jayapal Reddy Uradi
wrote:
> Hi Girish,
>
> While selecting the delay I suggest the following.
>
> In general check the time taken for the router boot up.
> Ta
Hi Girish,
While selecting the delay I suggest the following.
In general check the time taken for the router boot up.
Take the max interval as 10 times of boot up time.
Repeat the ssh for each boot up interval.
Thanks,
Jayapal
On 30-Sep-2013, at 1:38 PM, Girish Shilamkar
wrote:
> Marcus,
Marcus,
I guess it no longer applies to even KVM . I have seen the router in running
state and yet fails to accept
ssh connection.
Santhosh,
Adding random delay is what I am trying to avoid or at least minimise. Thanks
for the suggestions.
Regards,
Girish
On 30-Sep-2013, at 12:18 PM, Marcus
In the past, with KVM, the agent doesn't show the router as running until
it can ssh to it. You can watch the agent poll if it is debug logging. Does
this issue not apply to KVM, or is it a regression?
On Sep 29, 2013 11:38 PM, "Girish Shilamkar" wrote:
> Hello,
>
> Egress rules tests rely on acc
rom: Girish Shilamkar [gir...@clogeny.com]
> Sent: Monday, September 30, 2013 1:38 AM
> To: dev@cloudstack.apache.org
> Subject: Virtual Router reachability
>
> Hello,
>
> Egress rules tests rely on accessing virtual router VR after creating a
> network. I have often seen that VR i
t: Virtual Router reachability
Hello,
Egress rules tests rely on accessing virtual router VR after creating a
network. I have often seen that VR is not immediately accessible.
A ssh to VR fails, I think it takes a while for the network to come up and VR
can be ssh'd. This happens even thou
Hello,
Egress rules tests rely on accessing virtual router VR after creating a
network. I have often seen that VR is not immediately accessible.
A ssh to VR fails, I think it takes a while for the network to come up and VR
can be ssh'd. This happens even though the VR is in "Running"
state.
So
