GRE isolation + XCP-NG

[UAnton]

problem

The documentation states that GRE is supported for network isolation.

If you specify the tag (as stated in the documentation), you can't select a created Network offering (GRE) when creating a network. If you remove the tag, the network appears, but the virtual router doesn't start.

 Start Router
(r-51-VM) class com.cloud.agent.api.UnsupportedAnswer cannot be cast to class com.cloud.agent.api.OvsFetchInterfaceAnswer (com.cloud.agent.api.UnsupportedAnswer and com.cloud.agent.api.OvsFetchInterfaceAnswer are in unnamed module of loader 'app')

versions

4.22, XCP-NG 8.3

[UAnton]

@weizhouapache Hi,
Can you help with this?
Thanks!

[weizhouapache]

@weizhouapache Hi, Can you help with this? Thanks!

@UAnton
I tested ovs with kvm before, but never used ovs with xcpng

[dheeraj12347]

Hi @UAnton ,
I’ll try to reproduce the problem on CloudStack 4.22 with XCP-ng 8.3 and look into the OVS/GRE router start failure (UnsupportedAnswer cannot be cast to OvsFetchInterfaceAnswer).
Is this approach sound's good ? Can I start working on this ?

[UAnton]

@dheeraj12347 Hi,
That would be great.

[dheeraj12347]

Hi @UAnton ,
I’ve added defensive handling in OvsTunnelManagerImpl.handleFetchInterfaceAnswer so that the code no longer unconditionally casts the first Answer to OvsFetchInterfaceAnswer.
The method now:

Checks for null/empty Answer[].

Verifies answers instanceof OvsFetchInterfaceAnswer before casting.

Logs a clear warning and returns null when the agent returns UnsupportedAnswer (or any non-OvsFetchInterfaceAnswer).

Preserves the existing success path when a valid OvsFetchInterfaceAnswer with a non-empty IP is returned.

The change builds successfully on 4.22 with:
mvn -pl api,server -am -DskipTests clean install.

[DaanHoogland]

I’ve added defensive handling

@dheeraj12347 , please make a habbit of linking your PRs to issues or at least hastag-refer them. I have no idea what code you are referring to.

[dheeraj12347]

I’ve added defensive handling

@dheeraj12347 , please make a habbit of linking your PRs to issues or at least hastag-refer them. I have no idea what code you are referring to.

I’ve opened PR #12860 to add defensive handling in OvsTunnelManagerImpl.handleFetchInterfaceAnswer for this issue.