VR implementation on Shared network with multiple Guest IP ranges fails

[nvazquez]

problem

It was observed when creating a Shared network with multiple Guest IP ranges, the VR deployment fails but a parsing error:

null,"instanceType":null,"lastPolled":null,"lastUpdated":null,"processStatus":0,"removed":null,"result":null,"resultCode":0,"status":"IN_PROGRESS","userId":2,"uuid":"181dd803-48fb-4cae-bcdd-a4588a725ce4"}, job origin: 311 java.lang.NumberFormatException: For input string: "24,172.30.11.0"
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
	at java.base/java.lang.Long.parseLong(Long.java:709)
	at java.base/java.lang.Long.parseLong(Long.java:832)
	at com.cloud.utils.net.NetUtils.getCidrNetmask(NetUtils.java:971)
	at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.createGuestBootLoadArgs(VirtualNetworkApplianceManagerImpl.java:2198)
	at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeVirtualMachineProfile(VirtualNetworkApplianceManagerImpl.java:1991)
	at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeVirtualMachineProfile(VpcVirtualNetworkApplianceManagerImpl.java:363)

In my environment, the conflicting value is coming from the network cidr value as a comma-separated value from both ranges:

mysql> select id, name, network_cidr, cidr from networks where id = 214;
+-----+-------------+--------------+-------------------------------+
| id  | name        | network_cidr | cidr                          |
+-----+-------------+--------------+-------------------------------+
| 214 | Shared-Test | NULL         | 172.30.10.0/24,172.30.11.0/24 |
+-----+-------------+--------------+-------------------------------+
1 row in set (0.00 sec)

versions

4.22.0, 4.22.1

The steps to reproduce the bug

Scenario 1:

1. Create a Shared network
2. Add a second Guest IP range
3. Deploy VM on the network -> VR fails with error above

Scenario 1:

1. Create a Shared network
2. Deploy VM on the network -> succeeds
3. Add a second Guest IP range
4. Restart network with cleanup -> VR fails with error above

What to do about it?

No response

[weizhouapache]

this may be related to #11249
cc @sureshanaparti

[Dogface2k]

I traced this through the current 4.22 code and can confirm the exact failure mechanism. This is a regression caused by the interaction with #11249.

#11249 changed networks.cidr for shared networks from a single CIDR into a comma-separated list when multiple Guest IP ranges exist. It also introduced com.cloud.utils.StringUtils#getFirstValueFromCommaSeparatedString() and used that for backward-compatible API responses, but the internal singular CIDR helper was not updated.

The failing path is:

VirtualNetworkApplianceManagerImpl#createGuestBootLoadArgs()
  -> NetworkModelImpl#getValidNetworkCidr()
  -> NetUtils#getCidrNetmask()

getValidNetworkCidr() currently returns guestNetwork.getCidr() unchanged whenever network_cidr is null.

For:

172.30.10.0/24,172.30.11.0/24

NetUtils#getCidrNetmask() performs cidr.split("/"), producing:

[172.30.10.0, 24,172.30.11.0, 24]

It then calls:

Long.parseLong("24,172.30.11.0")

which reproduces the exact NumberFormatException reported here.

The correct repair point is NetworkModelImpl#getValidNetworkCidr(), because all of its production callers expect one CIDR and immediately pass it to single-CIDR netmask/DHCP calculations. NetUtils itself should remain a strict single-CIDR parser.

Suggested implementation:

@Override
public String getValidNetworkCidr(Network guestNetwork) {
    String networkCidr = guestNetwork.getNetworkCidr();
    String validNetworkCidr = networkCidr == null ? guestNetwork.getCidr() : networkCidr;
    return com.cloud.utils.StringUtils.getFirstValueFromCommaSeparatedString(validNetworkCidr);
}

This preserves network_cidr precedence, leaves null/empty/single-CIDR behaviour unchanged, and applies the same first-value compatibility already established by #11249.

Regression coverage should verify:

1. network_cidr still takes precedence;
2. a single fallback cidr is unchanged;
3. a comma-separated fallback cidr returns its first CIDR;
4. both reported runtime flows succeed:
   • initial VR deployment after adding a second Guest IP range;
   • network restart with cleanup after adding a second Guest IP range.