RVR for share network

[tuanhoangth1603]

problem

Hello,

Does RvR support for share network?
And how to make a network with standalone VR to redundant ?

I am facing an issue when make a network to redundant, the errlog from cmk restart network makeredundant=true cleanup=true id=<network_id>:
errortext": "Resource [DataCenter:1] is unreachable: Can't find all necessary running routers!

versions

Cloudstack 4.20 - KVM

The steps to reproduce the bug

No response

What to do about it?

No response

[tuanhoangth1603]

Also, I recently upgraded from 4.19 to 4.20. All existing networks (including isolated networks) must have a redundant VR; otherwise, I cannot create any VMs for these networks, and the management log will show the following error:
Unable to contact resource. com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is unreachable: Can't find all necessary running routers!

[weizhouapache]

@tuanhoangth1603
the VR for shared network only provides the service for Dhcp/Dns/Userdata
In my opinion, it is unnecessary to make it redundant.

anyway, the error message should be more clear and correct.

[tuanhoangth1603]

Thanks @weizhouapache, for your reply.
But there are some issues that I don't fully understand:

1. Why do I need to convert the VR to an RVR for an isolated network after upgraded from 19 > 20, even though the VR is still in a running state? After doing so, I can successfully create a new VM.
2. Similarly, for the VR of a shared network, I am unable to create a new VM, even though the network's VR is also running. So then I think it's need to make redundant

[weizhouapache]

Thanks @weizhouapache, for your reply. But there are some issues that I don't fully understand:

1. Why do I need to convert the VR to an RVR for an isolated network after upgraded from 19 > 20, even though the VR is still in a running state? After doing so, I can successfully create a new VM.
2. Similarly, for the VR of a shared network, I am unable to create a new VM, even though the network's VR is also running. So then I think it's need to make redundant

The version of scripts in VR should be consistent with the ACS version of the host and management server.
So you need to upgrade the VR, you can patch the VR, but I suggest to restart the network/vpc with cleanup, which will

• create new VR
• destory old VR

for shared network, no downtime as the VR is not VM gateway.
for isolated network without RVR, there might be few seconds downtime.

No need to make the network/vpc redundant

[tuanhoangth1603]

I restarted the shared network with cleanup, but it showed the following error:
Resource [DataCenter:1] is unreachable: Can't find all necessary running routers!
This issue occurs in both cmk and the UI.

[tuanhoangth1603]

I have found the cause.

When I make the VR to an RVR with cmk, even though it failed to become redundant, but it still changed the value of the redundant column in the networks table to 1. As a result, the network was unable to restart
In my opinion, if a shared network does not require an RVR, we should provide a clearer notification when someone attempts to convert a VR to an RVR and ensure that the redundant column value remains unchanged to 1.

[tuanhoangth1603]

Thanks @weizhouapache, for your reply. But there are some issues that I don't fully understand:

1. Why do I need to convert the VR to an RVR for an isolated network after upgraded from 19 > 20, even though the VR is still in a running state? After doing so, I can successfully create a new VM.
2. Similarly, for the VR of a shared network, I am unable to create a new VM, even though the network's VR is also running. So then I think it's need to make redundant

The version of scripts in VR should be consistent with the ACS version of the host and management server. So you need to upgrade the VR, you can patch the VR, but I suggest to restart the network/vpc with cleanup, which will

• create new VR
• destory old VR

for shared network, no downtime as the VR is not VM gateway. for isolated network without RVR, there might be few seconds downtime.

No need to make the network/vpc redundant

Also, restarting the network helped fix the issue mentioned in this topic.
Thanks @weizhouapache