Am 21.06.2018 um 17:08 schrieb Daan Hoogland:
> makes sense, well let's hope all breaks soon ;)
I am sure it will break! :D
And then I will get back to you with more questions!
Thanks a lot for taking the time!
>
> On Thu, Jun 21, 2018 at 2:15 PM, Melanie Desaive <
>
makes sense, well let's hope all breaks soon ;)
On Thu, Jun 21, 2018 at 2:15 PM, Melanie Desaive <
m.desa...@heinlein-support.de> wrote:
> Hi Daan,
>
> Am 21.06.2018 um 15:29 schrieb Daan Hoogland:
> > Melanie, attachments get deleted for this list. Your assumption for the
> > comm path is right
Hi Daan,
Am 21.06.2018 um 15:29 schrieb Daan Hoogland:
> Melanie, attachments get deleted for this list. Your assumption for the
> comm path is right for xen. Did you try and execute the script as it is
> called by the proxy script from the host? and capture the return? We had a
> bad problem
Hi Daan,
thanks for your reply.
The latest occurance of our VRs going to UNKNOWN did resolve 24 hours
after it had occured. Nevertheless I would appreciate some insight into
how the checkRouter command is handled, as I expect the problem to come
back again.
Am 21.06.2018 um 10:39 schrieb Daan
Melanie, this depends a bit on the type of hypervisor. The command executes
the checkrouter.sh script on the virtual router if it reaches it, but it
seems your problem is before that. I would look at the network first and
follow the path that the execution takes for your hypervisortype.
On Wed,
Hi all,
we have a recurring problem with our virtual routers. By the log
messages it seems that com.cloud.agent.api.CheckRouterCommand runs into
a timeout and therefore switches to UNKNOWN.
All network traffic through the routers is still working. They can be
accessed by their link-local IP